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Voorwoord 


Dit onderzoek is gericht op de optimalisatie van het IT Incident Managment bij URENCO Nederland 
B.V. te Almelo. De gegevens voor dit onderzoek dateren vanuit de periode september 2013 tot en met 
maart 2014. Alhoewel de essentiéle procedures en instructies toendertijd al aanwezig waren en 
voldeden aan de wettelijke eisen, blijkt uit dit onderzoek dat de integratie van de verschillende 
documenten en de samenwerking tussen actoren geoptimaliseerd kon worden. Deze optimalisatie was 
gericht op het efficiénter en effectiever afhandelen van de mogelijke IT incidenten binnen de logistieke 
activiteiten van URENCO Nederland B.V., zodat zowel tijd als geld bespaard konden worden. 


In de tussentijd heeft URENCO Nederland B.V. zelf al stappen ondernomen om het IT Incident 
Management te optimaliseren, waardoor anno 2016 de probleemstellingen binnen dit onderzoek 
adequaat zijn opgelost. Met behulp van een centraal registratiesysteem voor de IT incidenten is er een 
transparant en gerichte samenwerking tot stand gekomen tussen de actoren van zowel URENCO 
Nederland B.V. als de externe IT leveranciers. 


URENCO Nederland B.V. blijft met het vernieuwde IT Incident Management gecertificeerd met het ISO 
27001 standaard voor informatiebeveiliging. Tevens voldoet de onderneming aan de vernieuwde 
wetgevingen, zoals de wijziging in de Nederlandse Wet Bescherming Persoonsgegevens en de 
aangekondigde Europese richtlijn Data Protection Directive 95/46/EC. 


Alhoewel er veel overlappingen zijn tussen de aanbevelingen van dit onderzoek en de daadwerkelijk 
uitgevoerde implementatie door URENCO Nederland B.V., heeft dit onderzoeksverslag geen invioed 
gehad op deze daadwerkelijke implementatie van het alternatieve IT Incident Management. 


Wegens de vertrouwelijke bedrijfsinformatie zijn de appendices niet aan het hoofdverslag toegevoegd. 
Tevens worden de interviews en interne documenten van URENCO Nederland B.V. die gedurende dit 
onderzoek zijn toegepast niet in de literatuurlijst opgenomen. 
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Managementsamenvatting 


Het afgelopen decennium is er binnen de URENCO Group getracht om een strategie te 
implementeren waarbij alle verrijkingslocaties dezelfde processen hanteren voor het licht 
verrijken van uranium. Een belangrijk element hierbij was het extern uitbesteden van het 
implementeren en beheren van de informatietechnologie, zodat kosten bespaard konden 
worden en de focus bij de kernprocessen kon worden gelegd. Deze strategie heeft echter tot 
inconsistenties binnen het IT Incident Management van URENCO Nederland B.V. geleid. 
Alhoewel de essentiéle procedures en instructies aanwezig zijn en voldoen aan de wettelijke 
eisen, blijkt uit dit onderzoek dat de integratie van de verschillende documenten en de 
samenwerking tussen actoren geoptimaliseerd kan worden. Deze optimalisatie is gericht op 
het efficiénter en effectiever afhandelen van de mogelijke IT incidenten binnen de logistieke 
activiteiten van URENCO Nederland B.V. 


Binnen het IT Incident Management zijn diverse problemen aanwezig, zoals verouderde 
technologieén binnen de IT infrastructuur, onduidlijke verantwoordelijkheden, inconsistente 
procedures en verschillende definities die door de verschillende actoren gebruikt worden. De 
kern van deze problemen ligt bij de afwezigheid van een gezamenlijke modellering van de 
bedrijfsprocessen, applicaties en IT infrastructuur, zowel binnen URENCO Nederland B.V. 
als bij de externe IT leverancier CSC Limited.Hierdoor wordt er het risico gelopen dat IT 
incidenten inefficiént en ineffectief afgehandeld worden. 


Het gezamenlijk modelleren van de bedrijfsprocessen, applicaties en IT infrastructuur kan 
worden opgelost door het modelleren van een Enterprise Architecture. Een Enterprise 
Architecture maakt het mogelijk om de services van de IT infrastructuur te koppelen aan de 
aanwezige applicaties.Ook kunnen de applicaties weer als input gemodelleerd worden voor 
de bedrijfsprocessen, zodat duidelijk is welke services geleverd worden en welke actoren 
hier gebruik van kunnen maken. Er wordt dus een plattegrond opgesteld waarbij de gehele 
organisatie in 6én oogopslag duidelijk wordt gemaakt. 


Deze Enterprise Architecturen helpen om de input van het IT Risk Management te 
verbeteren. De procedures van het IT Incident Management kunnen hierdoor consistent 
worden gemaakt, wat leidt tot betere communicatie, samenwerking en besluitsvorming bij de 
betrokken stakeholders. Tevens kunnen wijzigingen beter in kaart worden gebracht, zodat de 
procedures ook aangepast kunnen worden. 


Om een kwalitatief hoogwaardige Enterprise Architecture te kunnen waarborgen, dient 
echter wel de organisatiestructuur te worden aangepast. Na onderzoek blijkt de beste optie 
het implementeren van een horizontale team structuur binnen het IT Risk Management te 
zijn, wat aansluit op de strategie die door de URENCO Group is geimplementeerd. Voor 
ieder kernproces wordt een team samengesteld wat verantwoordelijk is voor het opstellen 
van een Enterprise Architecture. Deze Enterprise Architecture wordt daarna door hetzelfde 
team als input gebruikt voor het vormgeven van het IT Risk Management en het IT Incident 
Management. Het is belangrijk dat het team wordt samengesteld door alle stakeholders, 
zodat de Enterprise Architecture een representatieve modellering is van de werkelijkheid. De 
implementatie van procedures dient ook pas te worden gerealiseerd nadat alle teamleden de 
documenten hebben goedgekeurd. De verkregen procedures en werkinstructies dienen 
centraal te worden opgeslagen in het SAP ERP systeem. Tot slot zal het opstellen van een 
IT Incident Management procedure als template gebruikt kunnen worden door het IT Risk 
Management Team, waarbij IT incidenten voor zowel CSC als URENCO centraal 
geregistreerd worden in het SAP ERP Systeem. 


1. Introductie van het onderzoek 


Dit onderzoekverslag richt zich op het IT Incident Management binnen de onderneming 
URENCO Nederland B.V., een nucleaire onderneming gericht op het licht verrijken van 
uranium. Voordat de probleemidentificatie gestart wordt, zal er eerst een introductie gegeven 
worden op de onderneming, de informatievoorziening en het IT Incident Management: 


e Paragraaf 1.1. beschrijft de belangrijkste bedrijfskenmerken van de URENCO Group; 

e Paragraaf 1.2. gaat in op de geimplementeerde One URENCO strategie; 

e Paragraaf 1.3. geeft de invioeden van de One URENCO strategie op de 
informatievoorziening weer; 

e Paragraaf 1.4. omschrijft het IT Incident Management binnen de URENCO Group. 

e Paragraaf 1.5 beschrijft tot slot de initiéle probleemstelling met betrekking tot het IT 
Incident Management. 


Voor de inhoud van hoofdstuk 1 is er uitvoerig literatuuronderzoek uitgevoerd. De volledige 
informatie is weergeven in de volgende appendices: 
e Appendix A “Introductie van de onderneming”; 
Appendix B “Organogram URENCO Nederland B.V.”; 
Appendix C “Proceslandschap URENCO Group’; 
Appendix D “I/llustratie van een cascade’; 
Appendix E “/ntroductie URENCO’s informatievoorziening’, 


1.1. Introductie van de onderneming: de URENCO Group 


De URENCO Group is een nucleaire onderneming die rond 1970 is opgericht voor het licht 
verrijken van uranium met behulp van ultracentrifugetechnologie. URENCO heeft als missie 
om wereldwijd de ontwikkelde nucleaire producten, diensten en technologieén toe te passen, 
om zo aan de groeiende vraag naar duurzame energie te kunnen voldoen (URENCO 
Nederland B.V., 2011). Met een marktaandeel van 29% is de URENCO Group de grootste 
aanbieder van lichtverrijkt uranium. 


De URENCO Group beschikt over vier verrijkingslocaties: (1) Almelo, Nederland; (2) Gronau, 
Duitsland; (3) Capenhurst, het Verenigd Koninkrijk; (4) Eunice, Verenigde Staten. Het 
hoofdkantoor is gevestigd te Stoke Poges, het Verenigd Koninkrijk. Tevens zijn er diverse 
vestigingen ter ondersteuning van de uraniumverrijking, zoals het 50% belang in de 
productie van ultracentrifuges binnen de Almelose onderneming ECT. 


URENCO vervult een belangrijke rol binnen de nucleaire industrie. Natuurlijk uranium bevat 
namelijk twee isotopen, uranium-235 en uranium-238 in de verhouding 0,7% tot 99,3%. Een 
kerncentrale heeft een concentratie uranium-235 van ongeveer 4% nodig om de nucleaire 
reactie in stand te houden, vandaar dat het natuurlijke uranium verrijkt dient te worden. Het 
natuurlijke uranium wordt in de chemische verbinding uraniumfluoride (UFg¢) bij URENCO 
aangeleverd, na verrijking wordt het uranium in de vorm van UFg in stalen cylinders geleverd 
aan de splijtstofstaven fabrikanten. 


URENCO verrijkt het natuurlijke uranium met behulp van ultracentrifuges. Onder verlaagde 
druk wordt UF gas in de centrifuges door een cilindermotor aangedreven. Door het hoge 
toerental worden de uraniumisotopen gescheiden, het zwaardere uranium-238 wordt tegen 
de wand aangedrukt en het lichtere uranium-235 blijft meer in het midden. Zowel het verrijkte 
als het veramde gas worden afgetapt en vervolgens door meerdere centrifuges geleid. Na 
afkoeling en compressie vinden er wegingen en monsternames plaats ter behoud van de 
kwaliteit en veiligheid. Een volledig overzicht van de kern- en ondersteunende activiteiten is 
weergeven in Appendix C “Proceslandschap URENCO Group”. 


1.2. One URENCO strategie 


Gedurende de jaren 1990-1993 heeft de URENCO Group een sterke reorganisatie 
ondergaan, waar de onderneming zich vooral gericht heeft op de implementatie van de One 
URENCO strategie, zie tevens paragraaf A.1. “URENCO’s geschiedenis” in appendix A 
“Introductie van de onderneming”. Het standaardiseren en harmoniseren van de processen 
binnen iedere verrijkingslocatie heeft erin geresulteerd dat de bedrijfsvoering en 
beslissingsprocedures zowel efficiénter als effectiever plaatsvinden. Een tweede gevolg van 
de One URENCO strategie is dat de URENCO Group zich meer richt op de kernactiviteiten, 
de ondersteunende activiteiten worden in toenemende mate uitbesteed aan externe partijen. 


1.3. URENCO’s informatievoorziening 


De implementatie van de One URENCO strategie heeft ertoe geleid dat de levering van IT 
hardware grotendeels extern is uitbesteed. Voorheen werd de informatievoorziening per 
productielocatie georganiseerd zonder centrale aansturing (Oortman, 2013), echter hebben 
er sinds 2007 diverse wijzigingen plaatsgevonden: 

e Ten eerste wordt het IT beleid op groepsniveau vastgesteld; 

e Ten tweede is de informatievoorziening meer gefocust op de bedrijfsuitvoering; 

e Tot slot is een groot deel van de informatievoorziening geoutsourced naar externe 

leveranciers, voornamelijk CSC Computer Science Ltd . 


Dankzij de plaatsgevonden hervormingen omvat de IT organisatiestructuur tegenwoordig 
meerdere stakeholders. De vier voornaamste stakeholders zijn: (1) URENCO Group IT; (2) 
CSC Computer Science Limited; (3) Locale IT teams URENCO Nederland B.V.; (4) 
Technical Services URENCO Nederland B.V.. Appendix E “Introductie URENCO’s 
informatievoorziening” geeft een nadere omschrijving van de stakeholders en bijbehorende 
IT strategie. 


1.4. IT incident Management 


De kans bestaat dat er zich incidenten voordoen binnen de informatiesystemen van de 
URENCO Group. 


Definitie 1.1.: Een incident is een ongeplande gebeurtenis die resulteert in een onderbreking 
of het niet voldoen van de IT services (URENCO Limited & CSC Computer Sciences Limited, 
2007). 


URENCO heeft diverse procedures en werkinstructies met corrigerende maatregelen in 
werking gesteld, zodat de gevolgen van een IT incident en mogelijke herhalingen van een 
incident worden geminimaliseerd. Deze procedures en werkinstructies zijn door verschillende 
partijen (zowel intern als extern) op meerdere managementniveaus ontwikkeld, vanwege de 
ingevoerde One URENCO strategie. Gezamenlijk geven deze procedures en instructies 
vorm aan het Incident Management, Problem Management, Business Continuity 
Management en Crisis & Emergency Plan. 


1.5. Initiéle probleemstelling 


De Business Relationship Manager binnen URENCO Nederland B.V. heeft het vermoeden 
dat de implementatie van de ONE URENCO strategie binnen het IT Incident Management 
niet volledig is uitgevoerd. Er is veel inspanning geweest om de informatievoorziening van de 
URENCO Group, URENCO Nederland B.V. en CSC op elkaar af te stemmen. Echter 
hanteren de actoren verschillende procedures en standaarden ter afhandeling van IT 
incidenten. Deze initiéle probleemstelling zal gedurende de probleemidentificatie in het 
volgende hoofdstuk nader onderzocht worden. 


2. Probleemidentificatie 


Zoals omschreven in Appendix A “I/ntroductie van de onderneming” en paragraaf 1.5. “Initiéle 
probleemstelling” is het vermoeden dat de implementatie van de One URENCO strategie tot 
probleemstellingen heeft geleid binnen het IT Incident Management. Dit hoofdstuk heeft als 
doel om één van deze probleemstellingen te selecteren, zodat verder onderzoek mogelijk 
wordt gemaakt. 


Hoofdstuk 2 is als volgt opgebouwd: 

e Paragraaf 2.1. zal allereerst de problemen inventariseren; 

e In paragraaf 2.2. worden de geinventariseerde problemen aan elkaar gerelateerd met 
behulp van een probleemkluwen; 

e Paragraaf 2.3. richt zich het selecteren van het kernprobleem; 

e Paragraaf 2.4. gaat verder met de operationalisatie van het kernprobleem; 

e Vanuit de operationalisatie kunnen gedurende paragraaf 2.5. diverse 
onderzoeksvragen worden opgesteld. 


Voor de onderbouwing van hoofdstuk 2 dienen de volgende appendices ter ondersteuning: 
e Appendix F “/nventarisatie problemen.”; 
e Appendix G “Probleemkluwen’, 
e Appendix H “Toelichting probleemkluwen’, 


2.1. Inventarisatie problemen 


De inventarisatie van problemen binnen het IT Incident Management heeft plaatsgevonden 
met behulp diverse inleidende interviews bij URENCO Nederland B.V. te Almelo. Tevens is 
gebruik gemaakt van de beschikbare documentatie van URENCO Nederland B.V., URENCO 
Limited en CSC Computer Science Limited. Een overzicht met de gevonden problemen is 
weer te geven in Appendix F “Inventarisatie problemen”. 


2.2. Probleemkluwen 


Zodra de problemen geinventariseerd zijn, kan de samenhang van de problemen 
gevisualiseerd worden met behulp van een probleemkluwen, zie Appendix G 
“probleemkluwen”. De probleemkluwen heeft als voordelen de oorzaak en gevolg relaties 
weer te geven, biedt structuur binnen de probleemcontext en helpt bij de keuze van het 
kernprobleem. In Appendix H “Toelichting probleemkluwen” zullen de verbanden tussen alle 
problemen in de probleemkluwen nader toegelicht worden. 


Vanuit de probleemkluwen kunnen de problemen in twee categorieén worden 
geclassificeerd, tevens zijn de belangrijkste oorzaken weergeven: 
e Problemen die resulteren in een onvolledige business & IT alignment van het IT 
Incident Management: 
o Een onvolledige technologische modellering binnen de informatievoorziening; 
o Een onvolledige modellering van de applicaties binnen de 
informatievoorziening; 
o Een onvolledige bedrijfskundige modellering binnen de informatievoorziening. 
e Problemen die resulteren in een onduidelijke omschrijving van verantwoordelijkheden 
binnen het IT Incident Management en de operationele bedrijfsuitvoering. 
o Een onvolledige bedrijfskundige modellering binnen de informatievoorziening, 
zowel intern als extern; 
o Het ontbreken van voldoende documentatie betreffende de 
verantwoordelijkheden; 
o Een inconsistent documentenbeheer. 


Deze twee (hoofd)problemen leiden ertoe dat er onzekerheid ontstaat omtrent de efficiénte 
en effectieve afhandeling van incidenten binnen de informatievoorziening. De aanwezige 
inconsistenties kunnen leiden tot inadequaat handelen binnen het Incident Management, 
waardoor het risico op (economische) schade ten gevolge van een incident vergroot wordt. 


2.3. Kernprobleem 


Nu de samenhang van de problemen is gevisualiseerd met behulp van de probleemkluwen, 
kan het kernprobleem geselecteerd worden. Voordat wordt overgegaan op de 
daadwerkelijke keuze van het kernprobleem, zullen de problemen eerst visueel 
geclassificeerd worden tot algemene probleemstellingen. 


2.3.1. Classificatie van problemen 
Gebasseerd op de probleemkluwen in Appendix G “Probleemkluwen”, kunnen de problemen 
geclassificeerd worden. Figuur 2-1 geeft een schematische weergaven van de onderstaande 
classificering: 
e De problemen gerelateerd aan de onvolledige business & IT alignment: 
o De problemen gerelateerd aan de onvolledige modellering van de 
informatietechnologie. In figuur 2-1 groen gemarkeerd; 
o De problemen gerelateerd aan de onvolledige modellering van de applicaties. 
In figuur 2-1 blauw gemarkeerd; 
o De problemen gerelateerd aan de onvolledige modellering van de 
bedrijfsprocessen. In figuur 2-1 oranie gemarkeerd. 
e De problemen gerelateerd aan de onduidelijke verantwoordelijkheden: 
o De problemen gerelateerd aan de onvolledige modellering van de 
bedrijfsprocessen. In figuur 2-1 oranje gemarkeerd; 
o De problemen gerelateerd aan documentatie van verantwoordelijkheden. In 
figuur 2-1 rood gemarkeerd. 
o De problemen gerelateerd aan het inconsistente documentenbeheer. In figuur 
2-1 grijs paars gemarkeerd. 
e De problemen gerelateerd aan het inefficiént en ineffectief afhandelen van incidenten. 
In figuur 2-1 grijs gemarkeerd. 


Figuur 2-1: Classifisering van de vijf deelgebieden binnen de probleemkluwen. Het zwart omcirkelde 
probleem vormt het geselecteerde kernprobleem gedurende dit onderzoek. Deze afbeelding dient 
puur ter classificering, voor details zie Appendix G: “Probleemkluwen’”. 


2.3.2. Keuze en motivering kernprobleem 

Het gebrek aan een gezamenlijke modellering van de informatietechnologie, de applicaties 
en de bedrijfsprocessen vormt een invloedrijke oorzaak voor de onvolledige business & IT 
alignment van het IT Incident Management, aangezien dit probleem drie van de viljf 
classificaties in figuur 2-1 beslaat. Het gezamenlijke modelleringsprobleem heeft zelf geen 
onderliggende oorzaken, waardoor in overeenstemming met de theorie van Heerkens & van 
Winden (2012), als kernprobleem kan worden geselecteerd. Door het gebrek aan een 
gezamenlijke modellering van IT, applicaties & bedrijfsprocessen als kernprobleem te 
selecteren, zal de onvolledige business & IT alignment vanuit de drie relevante gebieden 
tegelijkertijid onderzocht worden. 


Een gezamenlijke modellering van de informatietechnologie, de applicaties en de 
bedrijfsprocessen zal leiden tot: 
e Een overzicht van de totale informatievoorziening binnen URENCO Nederland B.V.; 
e Inzichten in hoe het IT Incident Management aansluit op de informatievoorziening; 
e Een gedetailleerdere identificatie van de overige problemen in de probleemkluwen, 
zodat een raamwerk ter oplossing van de overige probleemstellingen ontstaat; 
e Een raamwerk ter verduidelijking van de omschreven verantwoordelijkheden. 
Een gezamenlijke modellering biedt dus kansen tot het oplossen van meerdere problemen. 
Het gebrek aan een gezamenlijke modellering kan daarom als kernprobleem worden 
geselecteerd (zie de zwarte cirkel in figuur 2-1). 
Kernproblemen URENCO Nederland B.V.: De gezamenlijke modellering van 
bedrijfsprocessen, ondersteunende applicaties en onderliggende IT infrastructuur ontbreekt 
momenteel binnen het IT Incident Management van URENCO Nederland B.V.. 


2.4. Operationalisering 
Nu het kernprobleem geformuleerd is, kan het handelingsprobleem worden opgesteld. 


Definitie 2.1: “Een handelingsprobleem is een door de probleemhebber waargenomen 
discrepantie tussen de norm en de realiteit” (Heerkens & van Winden, 2012). 


Ter opstelling van het handelingsprobleem is het dus van belang om eerst de huidige situatie 
te vergelijken met de gewenste situatie. Tevens is het vaststellen van de scope essentieel 
gezien de tijd die is voorgeschreven voor dit onderzoek. 


2.4.1. Realiteit en norm 

In de _huidige situatie (de realiteit) ontbreekt er bij URENCO Nederland B.V. een 
gezamenlijke modellering van de informatietechnologie, applicaties en bedrijfsprocessen, 
wat resulteert in een onvolledige business & IT alignment van het IT Incident Management. 
Deze onvolledige business & IT alignment leidt ertoe dat het IT Incident Management van de 
betrokken partijen inconsistenties bevat, waardoor het IT Incident Management niet volledig 
aansluit op de daadwerkelijk operationele informatiesystemen. Zodra een incident zich 
voordoet, bestaat de kans dat het incident inefficiént of zelfs ineffectief wordt afgehandeld. 


In de gewenste situatie (de norm) zorgt een volledige modellering van de drie vakgebieden 
binnen het informatiemanagement voor structuur, samenwerking en consistentie bij het IT 
Incident Management van URENCO Nederland B.V.. De procedures en instructies van de 
stakeholders sluiten foutloos op elkaar aan en zijn vrij van redundanties. Een goede 
business & IT alignment zal leiden tot een goede aansluiting van het IT Incident 
Management op de informatievoorzieningen, zodat incidenten efficiént en effectief 
afgehandeld kunnen worden. 
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2.4.2. Scope van het onderzoek 

De gezamenlijke modellering van de informatietechnologie, applicaties, bedrijfsprocessen 
binnen het IT Incident Management zal voor alle afdelingen binnen URENCO Nederland B.V. 
te veel tijd vergen. Vandaar dat dit onderzoek zich slechts focusseert op de logistieke 
activiteiten binnen het primaire proces van URENCO Nederland B.V.. Binnen URENCO 
Nederland B.V. is de afdeling Materials Handling (MH) verantwoordelijk voor deze logistieke 
activiteiten, zie tevens het organogram in Appendix B “Organogram URENCO Nederland 
B.V.”. De uiteindelijke oplossing dient echter voor de gehele URENCO Group toepasbaar te 
zijn. Vandaar dat het onderzoek afgesloten dient te worden met het in kaart brengen van 
algemene oplossingen, zie ook deelvraag 6 in paragraaf 2.5. “Onderzoeksvragen”. 


2.4.3. Handelingsprobleem 

Nu zowel het kernprobleem als de scope van het onderzoek duidelijk is gemaakt, kan het 
handelingsprobleem van dit onderzoek binnen URENCO Nederland B.V. geformuleerd 
worden. 

Handelingsprobleem Urenco Nederland B.V.: De efficiénte en effectieve afhandeling van 
IT incidenten binnen de primaire logistieke processen van URENCO’s Nederlandse afdeling 
“Materials Handling” raakt in het geding door het gebrek aan een gezamenlijke modellering 
van de informatietechnologieén, applicaties en bedrijfsprocessen. 


2.5. Onderzoeksvragen 


Het oplossen van het handelingsprobleem vereist diverse methoden en theoretische 
benaderingen. Om het overzicht te kunnen waarborgen, wordt het handelingsprobleem 
opgedeeld in meerdere onderzoeksvragen. Het beantwoorden van iedere onderzoeksvraag 
zal een bijdrage leveren aan de uiteindelijke oplossing van het handelingsprobleem. 


1. Wat zijn de voordelen voor het IT Incident Management, zodra de 
informatietechnologie, applicaties & bedrijfsprocessen gezamenlijk worden 
gemodelleerd?; 

2. Hoe is de informatievoorziening binnen de logistieke processen van URENCO’s 
Nederlandse afdeling “Materials Handling” momenteel ingericht, gezien vanuit een 
gezamenlijke modellering van de informatietechnologie, applicaties & 
bedrijfsprocessen?; 

3. Hoe is momenteel het IT Incident Management ingericht binnen de logistieke 
processen van URENCO’s Nederlandse afdeling “Materials Handling”, gezien vanuit 
een gezamenlijke modellering van de informatietechnologie, applicaties & 
bedrijfsprocessen?; 

4. Welke beperkingen zijn er binnen het IT Incident Management met betrekking tot de 
informatietechnologie, applicaties & bedrijfsprocessen die worden gebruikt door 
URENCO’s Nederlandse afdeling “Materials Handling”? 

5. Hoe kan de aansluiting van het IT Incident Management op de informatievoorziening 
geoptimaliseerd worden binnen de logistieke processen van URENCO’s Nederlandse 
afdeling “Materials Handling”?; 

6. Hoe kan een raamwerk worden opgesteld ter ontwikkeling van een consistent IT 
Incident Management beleid binnen de gehele URENCO Group? 


Onderzoeksvraag 1 tot en met onderzoeksvraag 4 betreffen de probleemanalyse, deze 
zullen met behulp van de onderzoekscyclus worden beantwoordt (Heerkens & Van Winden, 
2012), zie tevens hoofdstuk 4 “Literatuuronderzoek & onderzoeksmodel”. Onderzoeksvraag 
5 en onderzoeksvraag 6 richten zich echter meer op de oplossing van het 
handelingsprobleem en zullen met behulp van zeven stappen gedurende de vierde ABP fase 
“De formulering van alternatieve oplossingen” worden opgelost, zie hoofdstuk 6. 
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3. De probleemaanpak 


In hoofdstuk 2 “De probleemidentificatie” is het handelingsprobleem geformuleerd dat 
centraal staat binnen dit onderzoek. Dit hoofdstuk zal inzicht geven in hoe het 
handelingsprobleem wordt aangepakt. 


De formulering van de probleemaanpak omvat de volgende onderwerpen: 
e Paragraaf 3.1. geeft de toegepaste methodologie weer; 
e Paragraaf 3.2. behandelt het conceptueel projectontwerp; 
e Paragraaf 3.3. richt zich op het opstellen van een operationeel project plan; 


3.1. Methodologie 


Voor het oplossen van het geformuleerde handelingsprobleem in paragraaf 2.4., zal er eerst 
een methodologie geselecteerd worden. Dit onderzoek omvat een combinatie van twee 
methodologién, namelijk: 

e De Algemene Bedrijfskundige Probleemaanpak (Heerkens & van Winden, 2012); 

e The Open Group Architecture Framework (The Open Group, 2011). 


3.1.1. De Algemene Bedrijfskundige Probleemaanpak 

URENCO Nederland B.V. heeft te maken met diverse problemen binnen het IT Incident 
Management, zie paragraaf 2.1. “Inventarisatie problemen”. De Algemene Bedrijfskundige 
Probleemaanpak (voortaan aangeduid als ABP) is een geschikte methodologie voor het 
identificeren en vervolgens oplossen van het kernprobleem binnen de onderneming. 


De ABP bestaat uit de volgende zeven fasen: 

De probleemidentificatie; 

De formulering van de probleemaanpak; 

De probleemanalyse; 

De formulering van alternatieve oplossingen; 
De beslissing; 

De implementatie; 

De evaluatie. 


NOOR WON = 


De selectie van de ABP als methodologie voor dit onderzoek kent een viertal voordelen: 

e De ABP is op alle bedrijfskundige problemen toepasbaar. Deze algemene 
bruikbaarheid om de verschillende vakgebieden binnen het handelingsprobleem op te 
behandelen; 

e De ABP vormt een theoretisch raamwerk. In dit raamwerk kunnen meerdere 
theorieén, modellen en overige methodieken tegelijkertijd worden toegepast. Hoewel 
het handelingsprobleem momenteel al meerdere vakgebieden beslaat, zullen er 
gedurende het onderzoek meerdere nieuwe inzichten ontstaan. De ABP maakt het 
mogelijk om deze nieuwe inzichten in het onderzoek te verwerken. 

e De ABP maakt gebruik van de interactie tussen zowel wetenschappelijk onderzoek 
als praktijkgericht ontwerpen. Deze interactie stimuleert het creatief omgaan met 
wetenschappelijke kennis, zodat de uiteindelijke oplossing het handelingsprobleem 
adequaat op kan lossen; 

e Tot slot beslaat de ABP alle essentiéle onderdelen voor het oplossen van het 
handelingsprobleem. De methodiek beslaat niet alleen de probleemanalyse zelf, 
maar stimuleert ook tot het nadenken over de implementatie en evaluatie van de 
aanbevolen oplossing. Deze eigenschap van de ABP maakt het onderzoek relevanter 
voor de onderneming. 
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3.1.2. The Open Group Architecture Framework 

Zoals in paragraaf 2.4. “Operationalisering” staat weergeven, heeft het handelingsprobleem 
met name betrekking op het gezamenlijk modelleren van de informatietechnologie, 
applicaties & bedrijfsprocessen. Deze gezamenlijk modellering staat in de wetenschap 
bekend onder de term Enterprise Architecture, zie tevens hoofdstuk 4 “Literatuuronderzoek”. 


Definitie 3.1: “Enterprise architecture is the complete, consistent and coherent set of 
methods, rules, models and tools which guides the (re)design, migration, implementation and 
governance of business processes, organizational structures, information systems and the 
technical infrastructure of an organization according to a vision” (lacob et al., 2012). 


Het het oplossen van het handelingsprobleem zal leiden tot een coherente Enterprise 
Architecture, daarom is het van belang dat een bijpoassende methodologie wordt toegepast. 
Gedurende dit onderzoek wordt er gebruik gemaakt van The Open Group Architecture 
Framework (voortaan aangeduid als TOGAF), een raamwerk voor de ontwikkeling van een 
Enterprise Architecture (The Open Group, 2011). TOGAF beschikt over methoden en 
hulpmiddelen ter ondersteuning van de acceptatie, productie, het gebruik en onderhoud van 
een Enterprise Architecture. 


Centraal binnen TOGAF staat de Architecture Development Method (voortaan aangeduid als 
ADM)(The Open Group, 2011). Deze methode ondersteunt de continue ontwikkeling en 
beheersing van een Enterprise Architecture. De stappen met de onderliggende samenhang 
zijn weergeven in figuur 3-1. 


Figuur 3-1: De 9 fasen van de Architecture Development Method (The Open Group, 2011). 
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De volgende argumenten ondersteunen de keuze voor TOGAF als aanvullende 
methodologie: 

e TOGAF heeft als methodologie het voordeel alle fasen van een architecturale 
levenscyclus te doorlopen. Dit wordt vooral mogelijk gemaakt door de stapsgewijze 
Architecture Development Method, waarmee de methodologie zich onderscheid van 
overige EA raamwerken (Lankhorst & van Drunen, 2007) (Zarvic & Wieringa, 2006); 

e TOGAF is een generiek raamwerk dat kan worden aangevuld met specifiekere 
theorieén, modellen en methodieken. Hierdoor wordt tevens de integratie tussen 
TOGAF en de ABP mogelijk gemaakt; 

e Aangezien TOGAF een generiek raamwerk is, kan het worden ingezet bij een divers 
aantal bedrijfsprofielen; 

e TOGAF heeft een groot aanbod van richtlijnen en technieken ter ontwikkeling van de 
Enterprise Architecture. Er bestaat kKeuzevrijheid omtrent welke richtlijnen en 
technieken toegepast zullen worden, zodat het de methodologie op maat kan worden 
gemaakt voor de desbetreffende onderneming; 

e TOGAF houdt bij het ontwerpen van een Enterprise Architecture direct rekening met 
het beheer van diezelfde Enterprise Architecture. Hierdoor blijft de Enterprise 
Architecture in samenhang met de geldende procedures, richtlijnen en overige regels 
binnen de onderneming. Dankzij het modelleren van het beheer kunnen zaken als 
bijvoorbeeld IT sequrity, compliance, taken & verantwoordelijkheden verduidelijkt 
worden; 

e TOGAF leidt tot een betere integratie van opgeleverde producten en standaarden 
dankzij het Enterprise Continuum, Architecture Repository en Architecture Framework 
of Content (Alonso, Verdun & Caro, 2010); 

e TOGAF ondersteunt de modellering van IT security, wat van toepassing zal zijn bij de 
benatwoording van de derde onderzoeksvraag (Innerhofer-Oberperfler & Breu, 2006); 

e TOGAF is een methodologie die voldoet aan relevante ISO standaarden. 


3.1.3. ABP & TOGAF gecombineerd 

DE ABP en TOGAF hebben overeenkomsten die het geschikt maken om de twee 
methodologieén gedurende dit onderzoek te combineren. De ABP op zich vormt een 
geschikte methode ter oplossing van het handelingsprobleem in paragraaf 2.4. 
“Operationalisering”, aangezien het kernprobleem op een systematische wijze 
geidentificeerd, geanalyseerd en vervolgens opgelost wordt met behulp van diverse 
theoretische perspectieven. TOGAF is echter een methodologie die meer is gespecificeerd 
op de ontwikkeling, implementatie en beheersing van een Enterprise Architecture, waardoor 
TOGAF van waardevolle betekenis kan zijn. TOGAF heeft echter een grotere nadruk op het 
ontwikkelen van een Enterprise Architecture in plaats van het analyseren van de huidige 
informatievoorzieningen. Hier sluit de ABP beter aan met behulp van fase 3: “de 
probleemanalyse” en fase 4: “de formulering van alternatieve oplossingen”. 


Beide methodologién hebben dus diverse sterke punten, waardoor het combineren van de 
ABP met TOGAF zal leiden tot een methodologie die beter aansluit bij dit onderzoek. 
Combinatie is goed mogelijk, aangezien zowel de ABP als TOGAF is opgebouwd als een 
raamwerk waarin relevante theorieén, modellen en methodieken toegepast kunnen worden. 
De resulterende methodologie voor dit onderzoek is zichtbaar in figuur 3-2. Hierbij worden 
van de TOGAF ADM cyclus zowel fase B “Business Architecture’, fase C “Information 
Systems Architecture” als fase D “Technology Architecture” tweemaal doorlopen. De eerste 
reeks vindt plaats gedurende ABP fase 3 “De probleemanalyse”, zodat de huidige Enterprise 
Architecture geanalyseerd kan worden. De herhaling van de TOGAF ADM fasen B, C en D 
vindt plaats gedurende ABP fase 4 “De formulering van alternatieve oplossingen”, zodat met 
behulp van een gap analysis een verbeterde Enterprise resulteert. 
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Legenda 


Zowel ABP fase 1 “De probleemidentificatie” als 
ABP fase 2 “De formulering van de probleemaanpak” 


ABP fase 3 “De probleemanalyse” 


ABP fase 4 “De formulering van alternatieve 
oplossingen” 


ABP fase 5 “De beslissing” 


ABP fase 6 “De implementatie” 


ABP fase 7 “De evaluatie” 


a 


Figuur 3-2: Schematische weergave van de combinatie tussen de ABP en TOGAF. De ABP fasen zijn 
staan omcirkeld weergeven naast de relevante TOGAF ADM fasen, zie tevens de legenda. De zwarte 
pijlen weergeven de uiteindelijke methodologie die resulteert vanuit de omschreven combinatie. 


3.1.4. Leeswijzer 

De opbouw van dit onderzoek is grotendeels gebaseerd op de 7 stappen van de ABP. Zoals 
schematisch is weergeven in figuur 3-2, valt de ABP prima te combineren met de TOGAF 
ADM fasen. Binnen dit verslag is echter de ABP leidend voor de structuur. De TOGAF ADM 
fasen dienen als theoretische invulling van de ABP fasen. 


De probleemidentificatie heeft reeds plaatsgevonden in hoofdstuk 2 “Probleemidentificatie”. 
De probleemaanpak in dit hoofdstuk geeft duidelijkheid over de activiteiten die zullen 
plaatsvinden gedurende dit onderzoek. De wetenschappelijke theorieén die relevant zijn voor 
dit onderzoek, zullen nader toegelicht worden in hoofdstuk 4 “Literatuuronderzoek”. 


De resultaten vanuit het literatuuronderzoek dienen als input voor de probleemanalyse in 
hoofdstuk 5 “Probleemanalyse”. Gedurende de probleemanalyse zal antwoord worden 
gegeven op de eerste vier onderzoeksvragen die zijn opgesteld gedurende paragraaf 2.5. 
“Onderzoeksvragen’: 

e De probleemanalyse zal beginnen met het onderzoeken van de voordelen die 
voortkomen uit het opstellen van een Enterprise Architecture; 

e De tweede onderzoeksvraag zal de Enterprise Architecture voor de logistieke 
processen binnen URENCO’s Nederlandse afdeling “Materials Handling” 
omschrijven; 

e Vervolgens zal de Enterprise Architecture voor het IT Incident Management binnen 
de logistieke processen van URENCO’s Nederlandse afdeling “Materials Handling” 
geformuleerd worden; 

e Zodra de eerste drie onderzoeksvragen zijn beantwoord, kan de probleemanalyse 
afgesloten worden met een gap-analyse van het IT Incident Management binnen de 
logistieke processen van URENCO’s Nederlandse afdeling “Materials Handling”. Voor 
de gap-analyse is naast de huidige EA modellering tevens een gewenste EA 
modellering benodigd, waardoor nogmaals TOGAF fasen B, C & D doorlopen 
worden, zie figuur 3-2. Deze gewenste EA modellering kan gezien worden als een 
start van ABP fase 4 “De formulering van alternatieve oplossingen”. 

Deze generatie van oplossingen wordt behandeld gedurende de vierde ABP fase in 
hoofdstuk 6 “Generatie van alternatieve oplossingen”. Hier wordt antwoord gegeven op de 
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vijfde en zesde onderzoeksvraag, zie paragraaf 2.5. “Onderzoeksvragen”. Ook deze vierde 
ABP fase kan worden opgesplitst. Ten eerste zullen daadwerkelijke alternatieven worden 
gegenereerd ter oplossing van het handelingsprobleem. Ten tweede zullen diverse 
raamwerken worden gegenereerd voor verdere implementatie binnen URENCO Nederland 
B.V. en de URENCO Group. De beslissing zal ook in hoofdstuk 6 worden gemaakt in de 
vorm van het advies dat aan het management gegeven wordt. De daadwerkelijke beslissing 
wordt pas uitgevoerd na overleg van de resultaten. 


De aangedragen oplossing wordt omschreven en nader uitgewerkt in hoofdstuk 7 
“Implementatie”. Zowel de technische implementatie als de sociale implementatie van de 
uiteindelijke oplossing zullen nader uitgewerkt worden. De evaluatie zal niet worden 
behandeld gedurende dit verslag, aangezien eerst de definitieve beslissing genomen moet 
worden. 


3.2. Conceptueel project ontwerp 


Het conceptueel project ontwerp geeft een schematisch en globaal overzicht van het uit te 
voeren onderzoek. De volgende elementen staan centraal in het conceptueel projectontwerp 
(Van Aken, Berends, & Bij, 2007): 

e Het onderwerp van de analyse; 

e De theoretische benaderingen die gedurende de analyse worden toegepast; 

e Een confrontatie tussen de theoretische benaderingen en het onderwerp van de 

analyse; 
e De op te leveren resultaten van het project. 


Aangezien het onderzoek zowel ontwerpgericht als theoriegericht is opgezet, zal er een 
continue interactie bestaan tussen de theoretische benaderingen en de praktijk. Deze 
interactie, die uiteindelijk zal leiden tot diverse resultaten, wordt met behulp van het volgende 


symbool gepresenteerd: 


Met behulp van hoofdstuk 2 “Probleemidentificatie” kan voor URENCO Nederland B.V. het 
conceptueel project ontwerp opgesteld worden, zoals schematisch weergeven in figuur 3-3. 


3.3. Operationeel project plan 


Het operationeel plan geeft een gedetailleerde omschrijving van de taken die uitgevoerd 
dienen te worden ter oplossing van het handelingsprobleem in paragraaf 
2.4.”Operationalisering”. Het operationeel plan is grotendeels gebaseerd op de toegepaste 
ABP methodologie, zie paragraaf 3.1. “Methodologie: Algemene Bedrijfskundige 
Probleemaanpak”. Het operationeel project plan is zichtbaar in Appendix | “Operationeel 
project plan”. 
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Theoretische perspectieven Onderzoeksonderwerp 


e IT Incident Management Een gebrek aan de gezamenlijke modellering van 
de informatietechnologie, applicaties, bedrijfs- 
processen binnen het IT Incident Management 
Informationmanagement; van de afdeling Materials Handling 


Crisis Management; 


Business & IT alignment; 
Enterprise Architecture; 
Business Process Modelling; 
Decision Making Processes; 


Change Management. 


Resultaten 
Gedetailleerde probleemkluwen, handelingsprobleem & onderzoeksvragen; 
Onderzoeksmethodologie, conceptueel project ontwerp, operationeel project plan & overzicht met deadlines; 
Literatuuronderzoek & resulterend onderzoeksmodel; 
Beantwoording van de onderzoeksvragen: 


= Voordelen voor het IT Incident Management zodra een gezamenlijke modellering van de informatietechno- 
logie, applicaties en bedrijfsprocessen wordt verkregen; 


Een layered view van de informatievoorziening binnen de primaire processtap Logistics Execution; 
Een layered view van het IT Incident Management binnen de primaire processtap Logistics Execution; 


Gap-analysis naar de integratie van de informatievoorziening en het Emergency Response beleid binnen de 
primaire processtap Logistics Execution; 


Alternatieve oplossingen ter optimalisatie van het IT Incident Management binnen de primaire processtap 
Logistics Execution; 


= Raamwerk ter ontwikkeling van een consistent IT Incident Management voor de URENCO Group; 
Uitwerking van de Multi Criteria Analyse, inclusief gevoeligheidsanalyse; 

Implementatieplan, zowel technisch als sociaal gericht; 

Evaluatieplan, zowel voor het onderzoek als de uiteindelijke oplossing; 


Eindconclusies, aanbevelingen & managementsamenvatting. 


Figuur 3-3: Schematische weergave van het conceptueel project ontwerp. 
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4. Literatuuronderzoek & Onderzoeksmodel 


De onderzoeksvragen in paragraaf 2.5. “Onderzoeksvragen” weergeven diverse 
onduidelijkneden weer die beantwoord dienen te worden gedurende de probleemanalyse. 
Voor de beantwoording van deze onderzoeksvragen worden wetenschappelijke artikelen 
toegepast in aanvulling van de pratijkgegevens die door URENCO Nederland B.V. zijn 
aangedragen. Het conceptueel project ontwerp in paragraaf 3.2. “Conceptueel project 
ontwerp” weergeeft de theoretische perspectieven die van toepassing zijn binnen het 
onderzoek. 


In Hoofdstuk 4 wordt relevante literatuur aangedragen ter oplossing van het 
handelingsprobleem. Deze aangedragen literatuur wordt verwerkt tot een onderzoeksmodel, 
waarmee vervolgens de probleemanalyse in Hoofdstuk 5 aangepakt kan worden. Voor het 
selecteren van deze literatuur wordt er gebruik gemaakt van een systematische aanpak, 
gebasseerd op de richtlijnen die zijn opgesteld door Kitchenham et al. (2007). 


Hoofdstuk 4 heeft de volgende opbouw: 
e Paragraaf 4.1. geeft de systematische aanpak voor het literatuuronderzoek; 
e Paragraaf 4.2. presenteert de resultaten van het literatuuronderzoek; 
e Paragraaf 4.3. presenteert het globale onderzoeksmodel dat kan worden toegepast 
binnen de probleemanalyse. Dit onderzoeksmodel is gebaseerd op de resultaten van 
het literatuuronderzoek uit paragraaf 4.2. 


4.1. Structuur literatuuronderzoek 
Een systematisch literatuuronderzoek kan worden opgedeeld in drie fases (Kitchenham et 
al., 2007): 

e Planning van het onderzoek; 

e Uitvoering van het onderzoek; 

e Rapportering van het onderzoek. 


In dit hoofdstuk zal uitsluitend de rapportering van het onderzoek aangedragen worden, 
zodat slechts de uiteindelijke conclusies van de relevante literatuur weergeven worden met 
behulp van het ontwikkelde onderzoeksmodel. De planning en uitvoering van het 
literatuuronderzoek staat als volgt gedocumenteerd in de Appendices: 

e De planning van het onderzoek is weergeven in Appendix J “Planning 
literatuuronderzoek’”. 

e Deuitvoering van het literatuuronderzoek is te vinden in Appendix K “Ujitvoering 
literatuuronderzoek”. Hier worden tevens de resultaten van het literatuuronderzoek 
weergeven. 

e De verkregen artikelen vanuit het top-down literatuuronderzoek zijn gedocumenteerd 
in Appendix L “Top-down literatuuronderzoek”. 

e De verkregen artikelen vanuit het bottom-up literatuuronderzoek zijn gedocumenteerd 
in Appendix M “Bottom-up literatuuronderzoek”. 

e De dataverzameling en kwaliteitsscoren binnen de gevonden artikelen is weergeven 
in Appendix N “Dataverzameling artikelen; 

e De kwaliteitsbeoordeling van de gevonden artikelen vindt plaats binnen Appendix O 
“Kwaliteitsbeoordeling artikelen”. 


4.2. Resultaten literatuuronderzoek 


Op basis van het de resultaten die zijn verkregen uit het literatuuronderzoek, kan een 
onderzoeksmodel worden opgesteld ter uitvoering van de probleemanalyse. Aangezien de 
probleemanalyse de beantwoording van de eerste vier onderzoeksvragen beslaat, wordt 
iedere onderzoeksvraag apart behandeld. 
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4.2.1 Resultaten literatuuronderzoek onderzoeksvraag 1 — EA voordelen 

Het Enterprise Architecture Benefits Model van Tamm, Seddon, Shanks & Reynolds (2011) 
wordt centraal gesteld bij de zoektocht naar EA voordelen. Het EA Benefits Model geeft aan 
hoe EA voordelen tot stand komen, dit door een duidelijk onderscheid te maken in benefit 
enablers en de organisational benefits, zie tevens figuur 4-71. Dit onderscheid is van belang, 
aangezien het opstellen van een EA mogelijkheden creéert om vervolgens de prestaties van 
de organisatie te verbeteren. De invloed van de EA kwaliteit wordt buiten beschouwing 
gelaten (relaties Pla, P2a, P3a en P4a). 


Organisational 
Alignment 
Pib, 
Information 
Availability " 


Resource Portfolio 
Optimisation 


Complementarity 


Figuur 4-1: Visualisatie van het EA Benefits Model van Tamm, Seddon, Shanks & Reynolds (2011). De variabele 
“Enterprise Architecture Quality” wordt bij dit onderzoek buiten beschouwing gelaten. 


De EA voordelen en toegepaste classificaties binnen de drie geselecteerde artikelen worden 
als data input gebruikt voor het EA Benefits Model. De classificatie van Niemi helpt de EA 
voordelen te verdelen tussen benefit enablers en organizational benefits. De clasificatie van 
Wan et al. helpt de relaties tussen benefit enablers en organizational benefits te leggen. 


4.2.2. Resultaten literatuuronderzoek onderzoeksvraag 2— EA modellering MH 
activiteiten 
Vanuit het plaatsgevonden literatuuronderzoek kunnen de volgende kernelementen 
geselecteerd worden die benodigd zijn voor een EA modellering van URENCO’s primaire 
(productie)proces: 

e EA raamwerk (Lankhorst & van Drunen, 2007)(Alonso, Verdtin & Caro, 2010); 

e EA modelleringstaal (Jonkers et al., 2003)(Lankhorst & van Drunen, 2007); 

e EA meta model (Lagerstr6ém, Saat, Franke, Aier & Ekstedt, 2009)(Saat, Franke, 

Lagerstrém & Ekstedt, 2010). 


Het Enterprise Architecture Framework waarop de modelleringstaal Archimate 2.0 is 
gebaseerd wordt als onderzoeksmodel toegepast bij de modellering van URENCO’s 
logistieke activiteiten (Jonkers et al., 2003). De processen en componenten kunnen binnen 
drie lagen gemodelleerd worden: (1) de Business Layer; (2) de Application Layer & (3) de 
Technology Layer. Binnen iedere modelleringslaag kunnen drie elementen gemodelleerd 
worden: (1) de actieve structuur elementen; (2) de gedragselementen & (3) de passieve 
structuur elementen. Zie appendix P “ArchiMate EA Meta Model” voor een nadere toelichting 
van de te modelleren elementen en de bijbehorende definities. 


Jonkers et al. maken op basis van deze lagen en elementen zeven architectuurdomeinen die 
gemodelleerd dienen te worden: (1) het product; (2) de organisatie; (3) het proces; (4) de 
informatie; (5) de data; (6) de applicaties & (7) de technologie. Zie figuur 4-2 voor het 
onderzoeksmodel van deze zeven variabelen. 
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Figuur 4-2: Het Enterprise Architecture Framework waarop de modelleringstaal ArchiMate 2.0 is gebaseerd 
(Jonkers et al., 2003). Het Framework vormt het onderzoeksmodel binnen onderzoeksvaag 2. 


Business 


Application 


Het Enterprise Architecture Framework zal worden aangevuld met de volgende modellen: 

e Het negenviaksmodel van Maes (2008) voor de stakeholderidentificatie; 

e De Meta Modeling Method van Lagerstrém et al. (2009) voor het op maat maken van 
de EA modellering. Input van dit model wordt verkregen vanuit het ArchiMate EA 
Meta Model, zie appendix P “ArchiMate EA Meta Model; 

e De RASCI matrices van Cabanillas et al. (2011) voor het in kaart brengen van taken, 
bevoegdheden & verantwoordelijkheden; 

e Het Enterprise Continuum vanuit TOGAF, zie appendix Q “Enterprise Continuum”. 


4.2.3. Resultaten literatuuronderzoek onderzoeksvraag 3— EA modellering IT Incident 
Management 

Het onderzoeksmodel voor de EA modellering is al omschreven in figuur 4-2 binnen 
paragraaf 4.2.2. “Resultaten literatuuronderzoek onderzoeksvraag 2— EA modellering MH 
activiteiten”. 


Bij de EA modellering van onderzoeksvraag 3 dienen specifieke kenmerken van het IT 
Incident Management gemodelleerd te worden in het proces domein. Het IT incident 
Management is het proces waarbij de normale services van de IT zo spoedig mogelijk 
worden hersteld met minimale verstoringen binnen de bedrijfsprocessen (Barash, Bartolini& 
Wu, 2007)(Bartolini, Stefanelli & Tortonesi, 2008)(Bartolini, 2009). Het IT incident 
Management omvat de activiteiten: (1) IT incident reporting; (2) Analyseren & classificeren 
van IT incidenten; (3) Toewijzen van relevante stakeholders ter oplossing van IT incidenten; 
(4) Repareren van IT failures; (5) Herstellen van IT services. 


Het IT Incident Management kan samen met het IT Risk Management worden 
geclassificeerd als IT Security Management (Laudon & Laudon, 2012). De modellering van 
het IT Risk Management zorgt dus voor de input van het IT Incident Management en omvat 
de activiteiten: (1) Risico’s identificatie; (2) Analyse risico’s; (3) Plannen van IT Risk Policies; 
(4) Implementeren van IT Risk Policies; (5) Monitoren van IT risico’s (Pauli, Schermann & 
Krcmar, 2010). 


4.2.4. Onderzoeksmodel gap analysis 

De Gap analyse die van toepassing is binnen de TOGAF Architecture Development Method 
zal worden toegepast om de huidige EA en de gewenste EA met elkaar te vergelijken (The 
Open Group, 2011)(Diefenthaler & Bauer, 2013). Met behulp van de gap analysis kan de 
validatie van informatiesystemen onderzocht worden. De gemodelleerde elementen binnen 
onderzoeksvraag 2 “EA modellering MH activiteiten” en onderzoeksvraag 3 “EA modellering 
IT Incident Management” dienen als input voor de huidige EA modellering. De vanuit het 
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literatuuronderzoek verkregen kernactiviteiten binnen het IT Risk Management en het IT 
Incident Management zullen als gewenste EA worden toegepast. 

Met behulp van een matrix kunnen inconsistenties, redundanties, benodigde investeringen, 
etc. opgespoord worden, zie figuur 4-3 voor vereenvoudigd voorbeeld van deze matrix. Deze 
matrices zullen worden ingevuld tijdens de probleemanalyse in hoofdstuk 5. 
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Figuur 4-3: De toegepaste matrix binnen de TOGAF gap analysis. Verticaal staat de huidige EA weergeven, deze 
worat vergeleken met de gewenste EA horizontaal. In de matrix die ontstaat kunnen fouten kenbaar worden 
gemaakt, zodat nieuwe en overbodige elementen geidentificeerd worden. Deze matrices zullen gedurende de 
probleemanalyse in hoofdstuk 5 worden ingevuld na het opstellen van de huidige en gewenste EA. 


4.3. Resulterend onderzoeksmodel 


Het literatuuronderzoek heeft inzicht gegeven in hoe de probleemanalyse in het volgende 
hoofdstuk eruit zal komen te zien. De vier relevante onderzoeksvragen hebben ieder een 
eigen selectie van relevante wetenschappelijke literatuur. De kern van het onderzoeksmodel 
voor het gehele onderzoek omvat de volgende elementen: 

e Een koppeling tussen EA voordelen met de geidentificeerde probleem in de 
probleemkluwen met behulp van het “Enterprise Architecture Benefits Model” (Niemi, 
2006)(Tamm, Seddon, Shanks & Reynolds, 2011)(Wan, Luo, Johansson & Chen, 
2013). Het Enterprise Architecture Benefits Model vormt het onderzoeksmodel binnen 
onderzoeksvraag 1.; 

e Het “Enterprise Architecture Framework’ waarop de modelleringstaal ArchiMate 2.0 is 
gebaseerd (Jonkers et al., 2003). Het raamwerk vormt het onderzoeksmodel binnen 
onderzoeksvaag 2 en onderzoeksvraag 3; 

e Het Enterprise Architecture Framework in onderzoeksvraag 3 wordt aangevuld met 
de activiteiten binnen het IT Risk Management (Barash, Bartolini& Wu, 
2007)(Bartolini, Stefanelli & Tortonesi, 2008) (Bartolini, 2009) en het IT Incident 
Management (Pauli, Schermann & Krcmar, 2010); 

e Een gap analysis wordt uitgevoerd binnen onderzoeksvraag 4 om de aansluiting van 
het IT Incident Management op de informatievoorziening te onderzoeken (The Open 
Group, 2011)(Diefenthaler & Bauer, 2013). 
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Binnen iedere onderzoeksvraag is dus een op maat gemaakt onderzoeksmodel van 
toepassing. Deze onderzoeksmodellen kunnen tot een algemeen onderzoeksmodel 
samengevat worden dat binnen de probleemanalyse van toepassing is. Figuur 4-4 geeft een 
schematische weergave van het resulterende onderzoeksmodel dat centraal staat bij 
hoofdstuk 5 “Probleemanalyse’”. 
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Figuur 4-4: Schematische weergave van het onderzoeksmodel ter oplossing van het handelingsprobleem. Het 
onderzoeksmodel omvat (1) de EA modellering van de MH activiteiten; (2) de EA modellering van het IT Incident 
Management; (3) de EA modellering van het gewenste IT Incident Management; (4) een gap analysis van de 
huidige en gewenste EA modellering betreffende het IT Management; (5) de link met de benefits enablers en 
organisational benefits. 
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5. Probleemanalyse 


Gedurende de probleemanalyse worden de eerste vier onderzoeksvragen nader onderzocht. 
Met het beantwoorden van deze onderzoeksvragen wordt inzicht verkregen in de huidige 
inrichting en tekortkomingen van de informatievoorziening en het IT Incident Management. 
De probleemanalyse dient hierdoor vooral als input voor de vierde ABP fase “Generatie van 
alternatieve oplossingen”. 


De opbouw van de probleemanalyse ziet er als volgt uit: 

e Paragraaf 5.1. “Onderzoekscyclus” behandelt de procedure om een onderzoeksvraag 
te beantwoorden (kennisprobleem); 

e Paragraaf 5.2. “Probleemanalyse onderzoeksvraag 1” behandelt de voordelen van 
een Enterprise Architecture binnen het IT Incident Management; 

e Paragraaf 5.3. “Probleemanalyse Onderzoeksvraag 2” gaat in op de huidige 
informatievoorzieningen binnen de logistieke processen van URENCO’s Nederlandse 
afdeling “Materials Handling”. 

e Paragraaf 5.4. “Probleemanalyse onderzoeksvraag 3” formuleert de huidige inrichting 
van het IT Incident Management binnen de logistieke processen van URENCO’s 
Nederlandse afdeling “Materials Handling”.; 

e Paragraaf 5.5 Probleemanalyse onderzoeksvraag 4” onderzoekt de tekortkomingen, 
redundanties en inconsistenties binnen de huidige informatievoorziening en het IT 
Incident Management van URENCO’s Nederlandse afdeling “Materials Handling”, 

e Paragraaf 5.6. “Conclusies probleemanalyse” herhaalt de kernpunten die zijn 
verkregen bij het beantwoorden van iedere onderzoeksvraag, zodat de input voor de 
vierde ABP fase “Generatie van alternatieve oplossingen” wordt verkregen. 


5.1. Onderzoekscyclus 


Voor het beantwoorden van de eerste vier onderzoeksvragen wordt er gebruik gemaakt van 
de onderzoekscyclus omschreven door Heerkens & van der Winden (2012). 


Definitie 5.1: “Een kennisprobleem is een beschrijving van de onderzoekspopulatie, de 
variabelen en, als het nodig is, de relaties die onderzocht moeten worden (Heerkens & van 
Winden, 2012). 


Het oplossen van een kennisprobleem verloopt via een vaste procedure van acht 
opeenvolgende fasen. Gezamenlijk vormen deze acht fasen de onderzoekscyslus: 
1. De doelstelling; 
De probleemstelling; 
De onderzoeksvragen; 
Het onderzoeksontwerp; 
De operationalisatie; 
De metingen; 
Het verwerken van de data; 
. Het trekken van de conclusies. 
De onderzoekscyclus wordt toegepast om de onderzoeksvragen vanuit de 
probleemidentificatie te beantwoorden. De uitgewerkte onderzoekscycli die gedurende de 
probleemanalyse worden behandeld, zijn nader uitgewerkt in de volgende appendices: 
e Appendix R “Onderzoekscyclus onderzoeksvraag 1 — EA voordelen’,; 
e Paragraaf S “Onderzoekscyclus onderzoeksvraag 2 — EA modellering MH 
activiteiten”. 
e Appendix T “Onderzoekscyclus onderzoeksvraag 3 — EA modellering IT Incident 
Management; 
e Appendix V “Onderzoekscyclus onderzoeksvraag 4 — Gap analysis. 


ONOTARWL 
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5.2. Probleemanalyse onderzoeksvraag 1 


Gedurende deze onderzoekscyclus staat onderzoeksvraag 1 centraal, zie tevens paragraaf 
2.5. “Onderzoeksvragen”. Deze onderzoeksvraag luidt als volgt: 

Onderzoeksvraag 1: Wat zijn de voordelen voor het IT Incident Management, zodra de 
informatietechnologie, applicaties & bedrijfsprocessen gezamenlijk worden gemodelleerd? 
De gehele onderzoekscyclus is zichtbaar in Appendix R “Onderzoekscyclus 
onderzoeksvraag 1- EA voordelen”. Gezocht wordt naar de voordelen die binnen de 
wetenschap bekend zijn betreffende het opstellen van een EA. Als datainput worden de 
artikelen van Niemi (2006), Tamm et al. (2011) en Wan et al. (2013) toegepast. Centraal 
staat hierbij het EA Benefits Model van Tamm et al., waarin onderscheid wordt gemaakt 
tussen de variabelen Benefit enablers en Organisational benefits: 

e Benefit enablers: factoren die duidelijk uitkomst zijn van een EA: (1) organisational 
alignment; (2) information availability; (3) resource portfolio optimalisation; (4) 
resource complementarity. Deze factoren hebben de potentie om organisatorische 
voordelen op te leveren; 

e Organisational benefits: factoren met een positief effect op de organisatie. Deze 
factoren zijn een indirect gevolg van de EA, maar hebben meerdere organisatorische 
factoren die van invloed zijn. 

De gevonden EA voordelen worden met behulp van antoniemen (het tegenovergestelde 
positieve effect van een probleem) gekoppeld aan de problemen die spelen binnen het IT 
Incident Management van URENCO Nederland B.V., zie hoofdstuk 2 “Probleemidentificatie”. 
Dit resulteert in een op maat gemaakt EA Benefit Model. 


Figuur 5-1 geeft een schematische weergaven van het resulterende EA Benefits Model, 
gespecialiseerd op het IT Incident Management van URENCO Nederland B.V.. 
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Figuur 5-1: Invulling van het Enterprise Architecture Benefits Model voor het IT Incident Management binnen 
URENCO Nederland B. V.. 
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Vanuit figuur 5-7 kunnen diverse conclusies kunnen getrokken worden met betrekking tot het 
IT Incident Management. Zo zijn de volgende EA voordelen het meeste van toepassing om 
de problemen binnen URENCO’s IT Incident Management te verhelpen: 

e Zowel de organisatorische afstemming, de informatie beschikbaarheid als de 
complementariteit van productiemiddelen zorgt voor een verbetering van de 
communicatie en samenwerking. De slechte communicatie en samenwerking is het 
meest voorkomende probleem binnen het IT Incident Management. Tevens kunnen 
hiermee gezamelijke doelstellingen (KPI’s) worden ontwikkeld; 

e Zowel de organisatorische afstemming, de informatie beschikbaarheid als de 
complementariteit van productiemiddelen zorgt voor een effectieve en versnelde 
besluitsvorming, wat de risico’s met betrekking tot beslissingen binnen het IT Incident 
Management verlaagt; 

e Zowel de organisatorische afstemming, de informatie beschikbaarheid als de 
complementariteit van productiemiddelen zorgt voor een verbeterd Change 
Management, waardoor wijzigingen binnen de IT of processen effectiever en 
efficiénter doorgevoerd kunnen worden; 

e De beschikbaarheid van informatie resulteerd in een verbeterde input van het RISK 
Management. Hierdoor worden de risico’s betreffende de genomen besluiten 
verkleind en wordt de IT veiligheid vergroot;’ 

e Decomplementariteit van productiemiddelen zorgt voor afstemming van de 
bedrijfsprocessen en procedures, wat momenteel binnen het IT Incident Management 
niet het geval is. De afstemming verhoogt de stabiliteit binnen de onderneming; 

e De verschillende organisatorische voordelen zullen uiteindelijk resulteren in diverse 
financiéle en economische voordelen, zoals efficiéntie in de bedrijfsprocessen & IT, 
verkorte cyclustijden, Kosten besparingen, doelgerichte investeringen en 
vereenvoudigde en versnelde (IT) implementaties. 


5.3. Probleemanalyse onderzoeksvraag 2 


Gedurende deze onderzoekscyclus staat onderzoeksvraag 2 centraal, zie tevens paragraaf 
2.5. “Onderzoeksvragen”. Deze onderzoeksvraag luidt als volgt: 

Onderzoeksvraag 2:Hoe is de informatievoorziening binnen de logistieke processen van 
URENCO’s Nederlandse afdeling “Materials Handling” momenteel ingericht, gezien vanuit 
een gezamenlijke modellering van de informatietechnologie, applicaties & 
bedrijfsprocessen?; 

De gehele onderzoekscyclus is zichtbaar in Paragraaf S “Onderzoekscyclus 
onderzoeksvraag 2- EA modellering MH activiteiten”. Centraal binnen dit onderzoek staat het 
onderzoeksmodel van Jonkers et al. (2003), waarin zeven architectuurdomeinen 
gemodellerd dienen te worden om tot een gezamelijke modellering (een layered view) te 
komen van de bedrijfsprocessen, applicaties en informatietechnologie. De zeven 
architectuurdomeinen vormen de variabelen binnen deze onderzoekscyclus: (1) het product; 
(2) de organisatie; (3) het proces; (4) de informatie; (5) de data; (6) de applicaties & (7) de 
technologie. 


Met behulp van de ontwikkelde layered views kan de informatievoorziening binnen de 
logistieke processen van URENCO’s Nederlandse afdeling “Materials Handling” omschreven 
worden. Figuur 5-2 weergeeft een voorbeeld van de layered view voor de processtap 1.a. 
“Bereidt cylinder voor”. 
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Externe rolien & actoren 


Figuur 5-2: De layered view van de activiteiten die door de MH operators worden uitgevoerd binnen 
processtap 1.a. "Bereidt cylinder voor". Deze gezamenlijke modellering van de Business Layer, 
Application Layer en Technology Layer dient als voorbeeld, de overige layered views zijn in Paragraaf 
S “Onderzoekscyclus onderzoeksvraag 2 — EA modellering MH activiteiten” weergeven. 
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Software integratie & centrale dataopslag URENCO Group 
1) SAP ERP 6.0 
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1) Plant Administration & Control System 


Verplaats cylinder intern 


Monitor cylinder & werkgebied 
radiologisch 


Inspecteer cylinder 


Weeg (inhoud) cylinder \\ Homogenisatie & monstername Controleer cylinder & 
\ \ kwaliteitsdata 


\ 


1) Cylinder Weighing System 
2) Cylinder Handling System 


1) 1S Sample Weighing System 
2) Plant Control System 


1) Cylinder Handling System 
2) Crane Control System 
3) Detailed Plannig System 
4) Nicelabel 


Figuur 5-3: Vereenvoudigde weergave van de MH activiteiten en de ondersteunende IT systemen met 
behulp van Porter's Value Chain Model (Laudon & Laudon, 2010). 


Vanuit de gemodelleerde layered views en het vereenvoudigde Value Chain Model kunnen 
diverse conclusies getrokken worden. Allereerst de bedrijfsmodellering, de MH 
kernactiviteiten omvatten: 
e Het intern verplaatsten van cylinders van/naar de (tussen-)opslaglocaties, 
voedingsstations en weegschalen; 
e Het inspecteren van de cylinders voor- en nadat de cylinders in productie worden 
genomen; 
e Het radiologisch monitoren van de cylinders en het werkgebied; 
e Het wegen van de cylinder (inhoud), de verkregen massa’s worden verwerkt in de 
uranium boekhouding; 
e Het homogeniseren van de cylinders ter monstername. De monsternames worden 
tevens gewogen voor de uranium boekhouding; 
e Het controleren van de cylinder & kwaliteitsdata ter afronding van het 
productieproces. 


Deze kernactiviteiten worden ondersteund door middel van verschillende applicaties: 

e Het verplaatsen van cylinders wordt aangestuurd door middel van het Cylinder 
Handling System. Input wordt verkregen vanuit SAP ERP 6.0 en diverse PDA's; 

e Het Cylinder Handling System stuurt het Crane Control System aan ter beweging van 
de transportkranen; 

e Nicelabel produceert de labels met essentiele informatie over de cylinder. De labels 
vormen een belangrijke input voor het Cylinder Handling System; 

e Het Cylinder Weighing System zorgt voor een goede verwerking van de massa’s die 
verkregen worden bij het wegen van de cylinders met behulp van cylinder 
weegschalen. De informatie wordt aan het Cylinder Handling System doorgegeven; 

e Het 1S Sample Weighing zorgt voor een goede verwerking van de massa’s die 
verkregen worden bij het wegen van de monstername ampullen. De output wordt aan 
SAP ERP 6.0 doorgecommuniceerd; 

e Het Detailed Planning System maakt de dagelijkse productieplanning beschikbaar en 
krijgt input vanuit SAP ERP 6.0 en het Process Administration & Control System. 

e Het Plant Control System houdt de proceskwaliteit in de gaten bij het 
verwarmen/afkoelen van de cylinders; 

e Het Process Administration & Control System zorgt voor de lokale dataverwerking 
binnen URENCO Nederland B.V.. De cylinder kwaliteitsdata wordt in dit systeem 
verwerkt; 

e SAP ERP 6.0 zorgt voor integratie van de verschillende in-confidence software en 
maakt een centrale dataopslag beschikbaar voor de gehele URENCO Group. 
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De software wordt ondersteund door de IT infrastructuur: 

e Diverse in-confidence software wordt lokaal gehost binnen URENCO Nederland B.V., 
zoals het Cylinder Handling System, het Crane Control System en het Detailed 
Planning System; 

e De in-confidence hardware is aan elkaar gelinked door middel van een In-confidence 
LAN; 

e De data op het in-confidence LAN wordt opgeslagen op een in-confidence storage 
network 

e Diverse classified software wordt lokaal gehost binnen URENCO Nederland B.V., 
zoals het Process Administration & Control System en het Plant Control System; 

e De classified hardware is aan elkaar gelinked door middel van een classified LAN; 

e De data op het classified LAN wordt opgeslagen op een classified storage network; 

e Diverse software wordt centraal gehost door CSC vanuit het Northern Data Centre, 
zoals het SAP ERP 6.0, het Cylinder Weighing System, 1S Sample Weighing System 
en het Database Management System; 

e Het in-confidence LAN heeft toegang tot de centraal gehoste software van CSC door 
middel van URENCO Encrypted WAN (geleverd door KPN); 

e De software voor het verplaatsen van de cylinders (Cylinder Handling System, Crane 
Control System en Nicelabel) bevatten diverse hardware componenten die dienen als 
interface voor de MH operators, zoals PDA’s, werkstations en Dolphin scanners; 

e De1S ampul weegschalen hebben een SOE computer ter beschikking voor het 
verwerken van de datainput; 

e Vanwege de strenge veiligheidseisen zijn de netwerken sterk beveiligd met bridge-to- 
bridge firewalls. 


De verkregen Enterprise Architectures binnen de afdeling “Materials Handling” bieden inzicht 
in de processen, informatievoorziening en IT infrastructuur. Deze inzichten zullen bijdragen 
aan het oplossen van het handelingsprobleem, omdat gekeken kan worden of alle 
componenten terugkomen in de procedures en werkinstructies van het IT Incident 
Management, zie onderzoeksvraag 3. 


5.4. Probleemanalyse onderzoeksvraag 3 


Gedurende deze onderzoekscyclus staat onderzoeksvraag 3 centraal, zie tevens paragraaf 
2.5. “Onderzoeksvragen”. Deze onderzoeksvraag luidt als volgt: 

Onderzoeksvraag 3: Hoe is momenteel het IT Incident Management ingericht binnen de 
logistieke processen van URENCO’s Nederlandse afdeling “Materials Handling”, gezien 
vanuit een gezamenlijke modellering van de informatietechnologie, applicaties & 
bedrijfsprocessen? 

De gehele onderzoekscyclus is zichtbaar in Paragraaf T “Onderzoekscyclus 
onderzoeksvraag 3- EA modellering IT Incident Management’. Centraal binnen dit onderzoek 
staat het onderzoeksmodel van Jonkers et al. (2003), waarin zeven architectuurdomeinen 
gemodellerd dienen te worden om tot een gezamelijke modellering (een layered view) te 
komen van de bedrijfsprocessen, applicaties en informatietechnologie. Hierbij worden 
dezelfde zeven architectuurdomeinen gemodelleerd als bij onderzoeksvraag 2. Omdat het IT 
Risk Management een belangrijke input vormt voor het IT Incident Management, worden 
beiden vakgebieden onderzocht en gemodelleerd. 
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Vanuit de EA modellering blijkt dat het IT Risk Management en het IT Incident Management 
door twee belangrijke partiien worden ontwikkeld: (1) URENCO Nederland B.V. zelf en (2) de 
externe IT leverancier CSC Limited. Voor beide partijen is een EA modellering gemaakt. 


5.4.1. EA modellering IT Risk Management URENCO Nederland B.V. 

De EA modellering van het IT Risk Management van URENCO Nederland B.V. is 
weergegeven in figuur 5-4. Geconcludeerd kan worden dat het IT Risk Management vooral is 
opgebouwd uit organisatorische aspecten, aangezien met name de bedrijfsmodellering 
invulling heeft gekregen. De volgende activiteiten worden ondernomen: 


1. De Business Relationship Manager interviewt de UNL Process Owners om de IT 
risico’s te identificeren; 

2. De Business Relationship Manager analyseert de IT risico’s door de data verkregen 
tiidens de interviews te verwerken in excel sheets. Met behulp van de sheets wordt 
een Business Impact Analysis gemaakt, waarvanuit de kritieke processen 
geselecteerd worden; 

3. De Process Owner stelt voor de kritieke processen een Business Continuity Plan op, 
in samenwerking met een UNL Compliance medewerker. Het Business Continuity 
Plan omvat: (1) de meldwijze voor IT incidenten; (2) het activeren van de 
workarounds; (3) het wegwerken van achterstanden nadat het IT Incident is 
verholpen; 

4. Een Compliance medewerker is verantwoordelijk voor het implementeren van het 
ontwikkelde Business Continuity Plan, waardoor de Business Continuity Plan’s in het 
bedrijfshandboek worden opgenomen en door de UNL Process Owners gebruikt kan 
worden; 

5. Nadat de IT risico’s zijn geinventariseerd en de Business Continuity Plan’s zijn 
opgemaakt, worden de IT risico’s gemonitord. Automatische monitoring wordt gedaan 
vanuit het CSC Network Management Centre met behulp van het Network 
Management System. Hier worden automatisch IT incidenten geregistreerd door 
middel van een IT Incident Log Ticket. Ook kunnen UNL process operators IT 
incidenten melden bij de Process Owner, die vervolgens het Business Continuity Plan 
in werking stelt. 


Het IT Risk Management van URENCO Nederland B.V. resulteert in geimplementeerde 
Business Continuity Plans en extra input van IT risico’s. Zo kunnen IT risico’s beter 
gemonitord worden door het Remote Management System binnen het CSC Network 
Management System. Het Remote Management System wordt door het CSC WAN met het 
CSC Northern Data Centre verbonden, wat weer in verbinding staat met de in-confidence 
netwerken van de URENCO Group. 


5.4.2 EA modellering IT Risk Management CSC Limited 

DE EA modellering van het IT Risk Management geleverd door CSC Limited is weergeven in 
figuur 5-5. Het IT Risk Management komt binnen CSC naar voren als het Problem 
Management voor de lange termijn. Het IT Risk Management omvat de volgende activiteiten: 


1. De dataverzameling (IT risico identificatie) wordt uitgevoerd met behulp van een 


trendanalyse. De IT incidenten worden verkregen vanuit de dataopslag van het 
Unicenter Service Desk System, waarin IT Incident Log Tickets worden opgeslagen; 

2. De resultaten van de uitgevoerde trendanalyse worden met behulp van een Root 
Cause Analysis geanalyseerd. Zodra de problemen zijn verkregen worden de 
problemen geclassificeerd & geprioriteerd. Deze verkregen kennis kan worden 
geupdate in de bijbehorende IT Incident Log Tickets in het Unicenter Service Desk 
System; 
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3. Zodra de problemen bekend zijn, kan er onderzocht worden welke IT componenten 
een workaround nodig hebben. De workarounds worden dus onderzocht, gecreéerd 
en gedocumenteerd; 

4. De ontwikkelde workarounds dienen geimplementeerd te worden in het 
bedrijfshandboek van CSC: “Knowledge Management Articles”. Bij uitvallen van de IT 
componenten waarvoor een workaround is opgesteld, kan het management van CSC 
een alternatief proces opstarten om de productie bij URENCO Nederland B.V. zo min 
mogelijk te beinvioeden. 


De IT incidenten worden dus verkregen vanuit de IT Incident Log Tickets binnen het 
Unicenter Global Service Desk System, gevestigd in het CSC Global Service Desk Utrecht. 
Dit systeem is toegankelijk voor de CSC medewerkers in URENCO Nederland B.V. omdat 
het systeem via het CSC WAN in verbinding staat met het Northern Data Centre, die weer in 
connecties heeft met de In-Confidence netwerken van de URENCO Group. 


Externe rollen & actoren 7 7 - ] 


|Bedrijfsprocessen & nitee actorenvrollen 


/ Monitoren van in- 
( confidence networks | 
} 


|Applicatie onderdelen & services + 


Externe ifrastructuur services 


Figuur 5-4: Gezamenlijke modellering (layered view) van het IT Risk Management dat door URENCO Nederland 
B.V. wordt toegepast. 
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Externe rollen & actoren 


Figuur 5-5: Gezamenlijke modellering (layered view) van het IT Risk Management dat door CSC Limited wordt 
toegepast. 
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5.4.3.EA modellering IT Incident Management 
De EA modellering van het IT Incident Management van URENCO Nederland B.V. is 
weergeven in figuur 5-6. De volgende activiteiten worden ondernomen: 


1. 


Het escaleren van het IT incident omvat met name de rapportering van het IT 
incident, zowel via monitoring door het Remote Management System als door het 
melden van de UNL gebruikers bij het CSC Global Service Desk (via de telefoon of 
via de SAP ERP interface). Zodra het IT Incident Log Ticket is aangemaakt gaat de 
UNL Information Security Manager over tot het vastleggen van de onderbroken 
systemen, zodat de fall-back scenario kan worden vastgesteld en de juiste IT resolver 
group kan worden geinformeerd: 

a. Scenario leidt de productie om via de virtuele omgeving van CSC; 

b. Scenario 2 omvat IT incidenten met een geschatte reparatietijd tussen 1 uur 
en 24 uur. Hierbij wordt het Disaster Recovery ICT mode geactiveerd; 

c. Scenario 3 omvat IT incidenten met een geschatte hersteltijd die langer is dan 
48 uur. Hierbij wordt het Crisis Management Team ingeschakeld. 

Zodra de juiste IT resolver group is geinformeerd, wordt er over gegaan tot de stap 
continuity planning & control: 

a. Bij scenario 2 wordt een Disaster Recovery plan opgesteld door de IT resolver 
group voor de codrdinatie, vervolgens wordt het juiste Disaster Recovery 
Team geactiveerd ter oplossing van het IT Incident; 

b. Bij scenario 3 eerst een crisisorganisatie bijgeen geroepen, het Crisis 
Management Team. Deze stelt ook een Disaster Recovery Plan voor de 
codrdinatie, net zoals bij scenario 2. Enig verschil is echter dat er nu een Root 
Cause Analysis wordt uitgevoerd voor het vinden van de onderliggende 
problemen. Deze analyse wordt door CSC uitgevoerd binnen het Major 
Incident Management proces. Zodra de problemen duidelijk zijn en verwerkt in 
het IT Incident Log Ticket (Unicenter Service Desk System), wordt het juiste 
Disaster Recovery team geactiveerd ter oplossing van het IT incident. 

Het herstellen van het IT incident wordt gedaan door het Disaster Recovery Team. 
Alternatieve systemen worden gestart en gemonitord voor de beveiliging van de 
informatie. Na het daadwerkelijk herstellen worden testen uitgevoerd en goedkeuring 
gevraagd bij de UNL gebruikers met behulp van een Key User Acceptance Test. 
Mocht het IT incident niet verholpen zijn, dan wordt er opnieuw een IT resolver group 
toegewezen. Updates worden verwerkt in het IT Incident Log ticket (Unicenter Global 
Service Desk System); 

Nadat het IT incident is hersteld, wordt door middel van opereren het gehele 
informatiesysteem weer in de juiste toestand gebracht; 

Tot slot wordt de normale productieomgeving hersteld door middel van een plan voor 
terugkering. Dit plan dient goedgekeurd te worden door de URENCO Group IT, 
voordat het plan daadwerkelijk wordt geimplementeerd. Bij positieve testresultaten 
wordt het IT Incident Log ticket afgesloten, bij negatieve testresultaten zal een nieuwe 
melding worden gemaakt van een IT incident. 


Gedurende de escalatie worden IT incidenten geregistreerd en opgeslagen als IT Incident 
Log Ticket binnen het Unicenter Global Service Desk System. IT incidenten kunnen gemeld 
worden door UNL gebruikers via de telefoon (opgenomen in de Business Continuity Plan’s) 
of via de SAP ERP interface. Ook kunnen IT incidenten automatisch geregistreerd worden 
door het Network Management System. Gedurende het verhelpen van het IT incident 
worden updates in het IT Incident Log Ticket verwerkt. Het BOGMAR systeem kan IT 
incidenten verhelpen door CSC resolver groups toegang te geven in de IT systemen door 
remote takeovers. 
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Figuur 5-6: Gezamenlijke modellering (layered view) van het IT Incident Management dat door URENCO 
Nederland B.V. wordt toegepast. 
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5.4.4. EA modellering IT Incident Management CSC Limited 
De EA modellering van het IT Incident Management van URENCO Nederland B.V. is 
weergeven in figuur 5-7. De volgende activiteiten worden ondernomen: 


1. 


Ontvangst & registratie van IT incidenten kan zowel via monitoring door het Remote 
Management System als door het melden van de UNL gebruikers bij het CSC Global 
Service Desk (via de telefoon of via de SAP ERP interface). Zodra het IT Incident Log 
Ticket is aangemaakt, beslist de CSC Service Desk medewerker of CSC Network 
Management Centre medewerker de severity level en prioriteit van het IT incident, 
tevens worden IT incidenten met een link gezocht. Tot slot wordt de juiste IT resolver 
group aangewezen en de UNL gebruiker geinformeerd; 

Het IT incident kan door drie actoren verholpen worden: 

a. IT incidenten worden naar externe leveranciers doorgecommuniceerd als 
CSC zelf niet verantwoordelijk is voor de beinvloede IT component; 

b. Het Standard Incident Management process wordt gevolgd bij IT incidenten 
met een Severity level 3. De IT resolver group wordt gecodrdineerd door 
aanmaken van een Disaster Recovery plan, het Disaster Recovery Team lost 
het IT incident daadwerkelijk op met behulp van technical recovery guides. Als 
het incident niet verholpen is, wordt een nieuwe IT resolver group 
aangewezen; 

c. Het Major Incident Management process wordt gevolgd bij IT incidenten met 
een Severity level 1 en 2. Het Major Incident Management proces treedt in 
werking en een Disaster Recovery plan wordt opgesteld om de IT resolver 
group te codrdineren (met onder andere het UNL Crisis Management Team 
en het CSC Major Incident Management Team). Na uitvoering van een Root 
Cause Analysis worden de gevonden problemen opgelost door het CSC 
Disaster Recovery Team met behulp van technical recovery guides. Als het IT 
incident niet verholpen is, wordt een nieuwe IT resolver group aangewezen. 

Bij sluiting van het IT incident is het incident verholpen en wordt er een Key User 
Acceptance Test uitgevoerd. Bij positieve resultaten wordt het IT Incident Log Ticket 
afgesloten, bij negatieve resultaten wordt een nieuwe IT resolver group 
samengesteld. 


Gedurende de escalatie worden IT incidenten geregistreerd en opgeslagen als IT Incident 
Log Ticket binnen het Unicenter Global Service Desk System. IT incidenten kunnen gemeld 
worden door UNL gebruikers via de telefoon (opgenomen in de Business Continuity Plan’s) 
of via de SAP ERP interface. Ook kunnen IT incidenten automatisch geregistreerd worden 
door het Network Management System. Gedurende het verhelpen van het IT incident 
worden updates in het IT Incident Log Ticket verwerkt. Het BOGMAR systeem kan IT 
incidenten verhelpen door CSC resolver groups toegang te geven in de IT systemen door 
remote takeovers. 
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Figuur 5-7: Gezamenlijke modellering (layered view) van het IT Incident Management dat door CSC Limited wordt 
toegepast. 
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5.5. Probleemanalyse onderzoeksvraag 4 


Gedurende deze onderzoekscyclus staat onderzoeksvraag 4 centraal, zie tevens paragraaf 
2.5. “Onderzoeksvragen”. Deze onderzoeksvraag luidt als volgt: 

Onderzoeksvraag 4:Welke beperkingen zijn er binnen het IT Incident Management met 
betrekking tot de informatietechnologie, applicaties & bedrijfsprocessen die worden gebruikt 
door URENCO’s Nederlandse afdeling “Materials Handling’? 

De gehele onderzoekscyclus is zichtbaar in Paragraaf V “Onderzoekscyclus 
onderzoeksvraag 4- Gap Analysis”. Centraal binnen dit onderzoek staat de Gap Analysis die 
van toepassing is binnen de TOGAF Architecture Development Method, zie tevens figuur 4-3 
(The Open Group, 2011)(Diefenthaler & Bauer, 2013). Door middel van een matrix waarin 
zowel de gewenste als huidige Enterprise Architecturen naast elkaar worden gelegd, kunnen 
inconsistenties, redundanties, benodigde investeringen, etc. opgespoord worden ter validatie 
van het informatiesysteem. 


De gemodelleerde elementen binnen onderzoeksvraag 2 “EA modellering MH activiteiten” en 
onderzoeksvraag 3 “EA modellering IT Incident Management” dienen als input van de Gap 
Analysis voor de variabele huidige EA modellering. De vanuit het literatuuronderzoek 
verkregen kernactiviteiten binnen het IT Risk Management en het IT Incident Management 
behoren bij de variabele gewenste EA modellering (Pauli, Schermann & Krcmar, 
2010)(Barahs, Bartolini & Wu, 2007)(Bartolini, Stefanelli & Tortonesi, 2008)(Bartolini, 2009). 
Bij de Gap Analysis staat het Enterprise Archimate Framework (Jonkers et al.,2003) centraal. 


5.5.1. Gewenste EA modellering 
Figuur 5-8 en figuur 5-9 weergeven de gewenste EA modelleringen (layered views) van de 


bedrijfsprocessen, applicaties en IT infrastructuur ter ondersteuning van het gewenste IT 
Risk Management en IT Incident Mangement. 


Voor het gewenste IT Risk Management in figuur 5-8 kan geconcludeerd worden dat in 
ieder geval de volgende activiteiten inbegrepen moeten zijn: (1) Risico’s identificatie; (2) 
Analyse risico’s; (3) Plannen van IT Risk Policies; (4) Implementeren van IT Risk Policies; (5) 
Monitoren van IT risico’s. Bij de activiteiten dienen zowel Business Managers als IT 
specialisten samen te werken om de IT risico’s te verzamelen en verwerken tot procedures. 
Een IT Incidenten Registratiesysteem dient aanwezig te zijn om IT risico’s vanuit de 
plaatsgevonden incidenten te verzamelen, een Enterprise Architecture ontwikkeling systeem 
om IT risico’s vanuit de aanwezige systemen te identificeren en analyseren. Een Monitoring 
Systeem houdt de escalatie van IT risico naar IT incident in de gaten. De systemen zijn 
geintegreerd door middel van het Enterprise Systeem, waardoor data transparant wordt voor 
alle actoren en de verkregen documentatie centraal opgeslagen kunnen worden. 


Voor het gewenste IT Incident Management _in figuur 5-9 kan geconcludeerd worden dat in 
ieder geval de volgende activiteiten ingebrepen moeten zijn: (1) IT incident reporting; (2) 
Analyseren & clasificeren van IT incidenten; (3) Toewijzen van relevante stakeholders ter 
oplossing van IT incidenten; (4) Repareren van IT defecten; (5) Herstellen van de IT 
services. Een IT support organisatie dient aanwezig te zijn ter uitvoering van de activiteiten, 
bestaande uit een helpdesk en een netwerk van support groups (verschillende levels). IT 
incidenten dienen geregistreerd en bijgewerkt te worden in een troubleticket met behulp van 
een IT Incidenten Registratiesysteem. Het troubleticket dient voor alle stakeholders in het IT 
Incident Management proces beschikbaar te zijn, voor een effectieve en efficiénte herstelling 
van de IT services. Dit kan worden gedaan door de systemen te linken met het Enterprise 
System. Een Monitoring Systeem helpt bij de automatische rapportering van IT incidenten, 
een Remote Takeover Systeem helpt op afstand de IT incidenten te verhelpen. 
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Figuur 5-8: Gezamenlijke modellering (layered view) van de bedrijfsprocessen, applicaties en IT infrastructuur ter 


ondersteuning van het gewenste IT Risk Management. 
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Figuur 5-9: Gezamenlijke modellering (layered view) van de bedrijfsprocessen, applicaties en IT infrastructuur ter 
ondersteuning van het gewenste IT Incident Management. 
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5.5.2. Geconstateerde problemen vanuit de Gap Analyzes 

De Gap Analysis wordt gesplitst in drie onderdelen: (1) de Business Layer; (2) de Application 
Layer; (3) de Technology Layer. In alle drie de layers worden de gewenste en huidige EA 
met elkaar vergeleken. Zowel voor het IT Risk Management als voor het IT Incident 
Management worden drie Gap Analysis gemaakt, zodat alle Layers geanalyseerd worden. 


Figuur 5-10 weergeeft een voorbeeld van hoe de Gap Analysis is uitgevoerd, deze Gap 
Analysis is gebasseerd op de Application Layer van het IT Risk Management. Duidelijk is dat 
er binnen URENCO Nederland B.V. slechts de gewenste Remote Monitoring System is 
gemodelleerd, bij CSC slechts het gewenste Registratie Systeem. Het EA Ontwikkeling 
Systeem en de verbinding met het Enterprise System ontbreken bij zowel URENCO 
Nederland B.V. als bij CSC Limited, deze systemen dienen dus nog geimplementeerd of 
gewijzigd te worden (zie de onderste rij in de tabel “nieuwe services’). 
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Figuur 5-10: Invulling van de Application Layer Gap Analysis voor het IT Risk Management van zowel URENCO 
Nederland B.V. als CSC Limited. 


De uitgevoerde Gap Analyses geven de inconsistenties, gebreken en redundanties binnen 
het IT Risk Management en IT Incident Management weer. De volgende problemen kunnen 
geconcludeerd worden vanuit de IT Risk Management Gap Analysis: 

e Alhoelwel de essentiéle activiteiten verdeeld zijn over URENCO Nederland B.V. en 
CSC Limited, ontbreekt er een gezamenlijke codrdinatie tussen beide 
ondernemingen. URENCO Nederland B.V. legt de focus op IT risico’s binnen het 
procesdomein, terwijl CSC Limited IT incidenten vanuit het verleden als input 
gebruikt; 
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e Een duidelijk start event ontoreekt voor het opstellen van nieuwe IT Risk policies. Dit 
geldt tevens voor het doorvoeren van plaatsgevonden wijzigingen binnen de 
Enterprise Architecture; 

e Eris geen directe samenwerking tussen de Business Managers en de IT specialisten, 
enige uitzondering is de Business Relationship Manager die interviews uitvoert en 
Business Impact Assessments opstelt; 

e DelT risico analyse binnen URENCO Nederland B.V. zijn beperkt gedocumenteerd, 
de risicobepalingen ontbreken in de opgeslagen Business Impact Assessments; 

e De opgestelde IT risk policies zijn niet volledig en inconsistent geimplementeerd, 
waardoor alreeds geactiveerde documenten verwijzen naar niet bestaande policies; 

e De opgestelde IT risk policies besteden slechts aandacht aan de beinviloede 
systemen, de bijbehorende kritieke processen worden buiten beschouwing gelaten. 

e URENCO Nederland B.V. maakt geen gebruik van de reeds plaatsgevonden IT 
incidenten die zijn opgeslagen binnen het IT Incidenten Registratie Systeem. Dit 
beperkt de input van de activiteit IT risico identificatie; 

e Zowel URENCO Nederland B.V. als CSC maakt geen gebruik van een Enterprise 
Architecture ontwikkeling systeem (of een soorgelijke tool) ter identificatie en 
analysatie van mogelijke IT risico’s; 

e De verkregen data, informatie en documentatie worden niet intern transparant 
gedocumenteerd met behulp van een Enterprise System. Dit gebeurt momenteel op 
de harde schijven die bij CSC en UNL beschikbaar zijn; 

e De lT infrastructuur van zowel URENCO Nederland B.V. als CSC Limited zijn 
toereikend om de gewenste Enterprise Architecture te ondersteunen, alleen de 
sofware ondersteuning voor een Enterprise Architecture ontwikkeling systeem en 
Enterprise Systeem dienen toegevoegd/uitgebreid te worden. 


Vanuit de IT Incident Management Gap Analysis resulteren de volgende problemen: 

e Binnen de documentatie van URENCO Nederland B.V. wordt geen rekening 
gehouden met de registratie, analyse en oplossing van IT incidenten binnen het 
Classified network, slechts de niet meer aanwezige TES Helpdesk wordt benoemd. 
Het melden van deze incidenten wordt wel in de Business Continuity Plans vermeld; 

e URENCO Nederland B.V. en CSC Limited hanteren verschillende classificaties van 
de IT incidenten. URENCO maakt gebruik van verwachte reparatietijden, CSC 
hanteert severity levels; 

e Binnen URENCO Nederland B.V. is de Information Security Manager 
verantwoordelijk voor de classificatie en analysatie van IT incidenten, echter beschikt 
hij niet over de juiste informatie op het moment dat het IT incident wordt gemeld. Het 
IT incident log ticket moet tijdiger bij deze actor aanwezig; 

e De actoren van URENCO Nederland B.V. worden binnen de processen van CSC 
Limited niet nadrukkelijk benoemd, met name de UNL gebruikers en UNL resolver 
groups dienen tijdig geinformeerd te worden; 

e Binnen CSC Limited worden essentiéle stappen ter herstelling van de IT services niet 
nader uitgewerkt, terwijl de stappen wel worden uitgevoerd en vermeld zijn binnen de 
documentatie van URENCO Nederland B.V.; 

e Erdient een overzicht te zijn van de kritieke systemen en bedrijfsprocessen ter 
herstelling van de totale productie na reparatie van het IT incident. Hiervoor 
ontbreken tevens de modellen van in de documentatie. 

e Bij het IT Incident Management (geleverd door CSC) dient het IT Incident Registratie 
Systeem uitgebreidt te worden binnen het SAP ERP 6.0 systeem met een User 
Interface of dashboard waar de UNL gebruikers de voortgang van het IT Incident 
Management proces kunnen bezichtigen. Dankzij een vergrote transparantie kan de 
hervatting van de productie effectiever en efficiénter gecodrdineerd worden. 

e De technologische infrastructuur voor het IT Incident Management is toereikend om 
de gewenste EA modellering tot stand te brengen. 
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5.6 Conclusies probleemanalyse 


De uitgevoerde probleemanalyse heeft geleid tot een aantal belangrijke conclusies met 
betrekking tot de de afhandeling van IT Incidenten binnen de primaire logistieke processen 
van URENCO Nederland B.V.. In deze paragraaf zullen de conclusies met elkaar in relatie 
worden gebracht, waarbij het onderzoeksmodel in figuur 4-4 als leidraad wordt gebruikt. 


Gedurende onderzoeksvraag 3 is de huidige Enterprise Architecture van het IT Incident 
Management binnen URENCO Nederland B.V. gemodelleerd, zie tevens paragraaf 5.4. 
“Probleemanalyse onderzoeksvraag 3”. Belangrijke kernpunten binnen het IT Incident 
Management zijn hieronder samengevat: 

e De taken, bevoegdheden en verantwoordelijkheden worden verdeeld tussen 
URENCO Nederland B.V. en de externe IT leverancier CSC Limited. De taken zijn 
afhankelijk van welke partij het desbetreffend falende IT component in beheer heeft. 
In het algemeen kan gesteld worden dat CSC het in-confidence network beheerd, 
URENCO Nederland B.V. het classified network; 

e De incidenten binnen IT componenten van CSC kunnen door UNL Process Owners 
worden gemeld bij de CSC Global Service Desk via de telefoon of het SAP ERP 
interface. Ook kunnen IT incidenten binnen het In-confidence network automatisch 
gemonitord worden door CSC Remote Management System. CSC registreert IT 
incidenten met behulp van het Unicenter Service Desk System. De incidenten binnen 
IT componenten van URENCO Nederland B.V. kunnen door UNL Proces Owners 
telefonisch gemeld worden bij de afdeling UNL Plant Maintenance; 

e Nade registratie en analysatie van het IT incident wordt de juiste resolver group 
ingeschakeld met behulp van belbomen. Hierbij wordt het probleem eerst 
geclassificeerd, zodat onderscheid gemaakt kan worden tussen standaard IT 
incidenten of ernstige IT incidenten (crisissituatie). Codrdinatie tussende actoren 
wordt verkregen door het opstellen van Disaster Recovery Plans; 

e Na herstellen van de falende IT component worden de IT services hersteld. Dit 
gebeurt m.b.v. testen, een Key User Acceptance Test en een plan van terugkering; 

e Tot slot zijn de activiteiten van het IT Risk Management gemodelleerd, aangezien 
hier de procedures en werkinstructies worden opgesteld ter voorkoming en 
afhandeling van IT incidenten. URENCO Nederland B.V. stelt procudures (met name 
Business Continuity Plans) op basis van IT risico’s binnen de bedrijfsprocessen. CSC 
analyseert de reeds plaatsgevonden IT incidenten en stelt hiervoor workarounds op. 


Om beperkingen binnen de huidige EA van het IT Incident Management (en IT Risk 
Management) te kunnen weergeven, is er een Gap Analysis uitgevoerd waarbij de huidige 
EA modellering wordt vergeleken met de gewenste EA modellering, zie tevens paragraaf 5.5. 
“probleemanalyse onderzoeksvraag 4”. De belangrijkste conclusie is dat de problemen 
binnen het IT Incident Management met name van organisatorische aard zijn, aangezien het 
overgrote deel van de inconsistenties, redundanties en beperkingen zich bevinden in de 
Business Layer. 


Binnen het IT Risk Management zijn de volgende beperkingen geconstateerd: 

e Een gezamenlijke codrdinatie tussen URENCO Nederland B.V. en CSC Limited 

ontbreekt; 

e Een duidelijk start event ontbreekt voor het opstellen van nieuwe IT Risk policies of 
voor het doorvoeren van wijzigingen binnen de Enterprise Architecture; 
Er is geen directe samenwerking tussen de Business Managers en de IT specialisten; 
De IT risico analyse binnen URENCO Nederland B.V. is beperkt gedocumenteerd; 
De opgestelde IT risk policies zijn niet volledig en inconsistent geimplementeerd; 
Binnen de opgestelde IT risk policies worden de kritieke processen waarop de 
falende systemen invloed hebben buiten beschouwing gelaten, een overzicht van de 
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processen, applicaties en IT ondersteuning ontbreekt, net zoals bijoassende software 
ter modellering; 

e DellT risico identificatie van URENCO Nederland B.V. wordt beperkt doordat de 
reeds geadministreerde IT incidenten binnen het Unicenter Service Desk System niet 
worden onderzocht; 

e Het SAP ERP 6.0 systeem biedt niet de mogelijkheid om de verschillede systemen te 
integreren, waardoor informatie en documentatie niet transparant wordt gedeeld. 
Informatie wordt intern opgeslagen op de harde schijven die beschikbaar zijn. 


De volgende beperkingen kunnen geconcludeerd worden vanuit de IT Incident 
Management Gap Analysis: 

e De documentatie van URENCO Nederland B.V. houdt geen rekening met de 
registratie, analysatie en oplossing van IT incidenten binnen het Classified network; 

e URENCO Nederland B.V. en CSC Limited hanteren verschillende classificaties van 
de IT incidenten; 

e De UNL Information Security Manager bezit niet over de juiste informatie op het 
moment dat het IT incident moet worden geanalyseerd; 

e De actoren van URENCO Nederland B.V. worden binnen de processen van CSC 
Limited niet nadrukkelijk benoemd en tevens niet tijdig geinformeerd; 

e Binnen CSC Limited worden essentiéle stappen ter herstelling van de IT services niet 
nader uitgewerkt, terwijl de stappen wel worden uitgevoerd; 

e Er dient een overzicht in de documentatie te zijn van de kritieke systemen en 
bedrijfsprocessen ter herstelling van de totale productie na reparatie van het IT 
incident, inclusief de geschikte software/tools voor de modellering; 

e De transparantie van het IT Incident Registratie Systeem dient te worden verbeterd 
voor de UNL gebruikers. 


De problemen binnen het IT Risk Management en IT Incident Management blijken 
voornamelijk van organisatorische aard te zijn, de meeste problemen resulteren namelijk 
vanuit de Business Layer Gap Analyzes. De actoren binnen URENCO Nederland B.V. en 
CSC Limited hanteren elk hun eigen systeemomschrijvingen, procedures en definities, wat 
resulteert in de hierboven omschreven inconsistenties. Ook is de voortgang van IT Incident 
Management niet transparant voor alle actoren. Binnen het IT Risk Management onbreekt 
een gezamenlijke codrdinatie en een centrale opslag van de opgestelde documentatie. 


De problemen binnen het IT Incident Management kunnen grotendeels verklaard worden 
door de inconsistenties die bestaan binnen het IT Risk Management, hier worden de 
procedures en werkinstructies namelijk vorm gegeven. Het hervormen van het IT Risk 
Management zal dus leiden tot een consistent IT Incident Management, zodat IT incidenten 
effectief en efficiént afgehandeld kunnen worden. Met name de organisatievorm vormt hierbij 
een punt van aandacht. 


Het gezamenlijk modelleren van de informatietechnologie, applicaties en bedrijfsprocessen 
met behulp van een Enterprise Architecture heeft dus geleid tot het in kaart brengen van het 
IT Risk Management, het IT Incident Management en de bijbehorende beperkingen. In 
paragraaf 5.3. “Probleemanalyse onderzoeksvraag 2” zijn de resulterende Enterprise 
Architectures van de primaire logistieke activiteiten gemodelleerd. Deze modellen laten zien 
op welke processen en systemen het IT Risk Management en IT Incident Management van 
toepassing zijn. Tevens bieden deze Enterprise Architectures de kans om de inconsistenties 
binnen het IT Risk Management en IT Incident Management te elimineren, bijvoorbeeld door 
het invoeren van een overzicht met de kritieke systemen en de beinvioede 
bedrijfsprocessen. 
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Tot slot kunnen met behulp van onderzoeksvraag 1 meerdere voordelen van een Enterprise 
Architecture benoemd worden die specifiek het IT Incident Management van URENCO 
Nederland B.V. kunnen verbeteren, zie tevens paragraaf 5.2. “Probleemanalyse 
onderzoeksvraag 1”. De eigenschappen van een Enterprise Architecture (benefit enablers) 
resulteren namelijk in de volgende organisatorische voordelen: (1) verbeterde input IT Risk 
Management; (2) verbeterde communicatie en samenwerking; (3) effectiever en versnelde 
besluitsvorming, (4) effectiever en efficiénter Change Management en (5) afstemming 
bedrijfsprocessen en procedures. Deze voordelen bieden hulp om de geconstateerde 
beperkingen binnen het IT Incident Management (en IT Risk Management) m.b.v. een 
Enterprise Architecture op te lossen 


Vanuit de probleemanalyse kan geconcludeerd worden dat de problemen binnen het IT 
Incident Management vooral van organisatorische aard zijn. Tevens wordt een groot deel 
van de problemen veroorzaakt door de wijze waarop de huidige procedures en 
werkinstructies worden opgesteld binnen het IT Risk Management. Dit kan als input worden 
gebruikt voor het genereren van alternatieve oplossingen, zie hoofdstuk 6 “Generatie van 
alternatieve oplossingen”. Dit moet helpen om het handelingsprobleem op te lossen: Het 
efficiénter en effectiever afhandelen van IT incidenten binnen de primaire logistieke 
processen van URENCO’s Nederlandse afdeling “Materials Handling”. 
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6. Generatie van alternatieve oplossingen 

Voor de gevonden beperkingen gedurende paragraaf 5.6 “Conclusies probleemanalyse” zal 
in dit hoofdstuk verschillende alternatieven geformuleerd en beoordeeld worden, zodat het 
handelingsprobleem opgelost kan worden. Dit gebeurt met behulp van zeven stappen 
(Heerkens & van Winden, 2012), uitgebreidt met een gevoeligheidsanalyse (Goodwin & 
Wright, 2010). De onderstaande paragrafen zullen dit proces duidelijk maken: 


De beslissing beschrijven, zie paragraaf 6.1.; 
Het beslissingsproces vaststellen, zie Paragraaf 6.2.; 
Criteria opstellen, een schaal en gewichten toekennen zie Paragraaf 6.3.; 
Alternatieven verzinnen of bestaande mogelijkheden gebruiken, zie Paragraaf 6.4.; 
Alternatieven beoordelen en gevoeligheidsanalyse, zie Paragraaf 6.5.; 

e Conclusies generatie van alternatieve oplossingen, zie Paragraaf 6.6. 
In appendix W “Generalisatie van alternatieven” is een uitgebreide omschrijving weergeven 
van de ondernomen stappen gedurende dit hoofdstuk. 


6.1. De beslissing beschrijven 


Voor de gevonden problemen bij onderzoeksvraag 4 dient een alternatief uitgewerkt te 
worden, zodat IT incidenten efficiént en effectief afgehandeld kunnen worden met behulp van 
de ontwikkelde Enterprise Architecturen. Allereerst dient er een consistent IT Incident 
Management ingericht te worden voor de afdeling “Material Handling” binnen URENCO 
Nederland B.V., waarbij zowel de informatietechnologie, applicaties als bedrijfsprocessen in 
overweging worden genomen. Vanuit de probleemanalyse kan geconcludeerd worden dat de 
problemen binnen het IT Incident Management vooral van organisatorische aard zijn, tevens 
wordt een groot deel van de problemen veroorzaakt door de wijze waarop de huidige 
procedures en werkinstructies worden opgesteld binnen het IT Risk Management. De keuze 
betreft dus een alternatieve organisatievorm van het IT Risk Management voor het opstellen 
van de juiste procedures en werkinstructies, waarmee er dus een antwoord zal worden 
gezocht voor onderzoeksvraag 5. 

Onderzoeksvraag 5: Hoe kan de aansluiting van het IT Incident Management op de 
informatievoorziening geoptimaliseerd worden binnen de logistieke processen van 
URENCO’s Nederlandse afdeling “Materials Handling”?; 

Binnen de URENCO Group wordt er echter gestreefd naar het stroomlijnen van de 
bedrijfsactiviteiten binnen alle verrijkingslocaties. Deze denkwijze komt naar voren in de 
geimplementeerde “One URENCO strategie”, zie paragraaf 1.2. “One URENCO strategie”. 
Vandaar dat er tevens aandacht moet worden besteedt aan het ontwikkelen van een 
oplossing dat binnen de gehele URENCO Group kan worden toegepast. Hiermee zal er dus 
een antwoord worden gezocht voor onderzoeksvraag 6. 

Onderzoeksvraag 6: Hoe kan een raamwerk worden opgesteld ter ontwikkeling van een 
consistent IT Incident Management beleid binnen de gehele URENCO Group? 

De beslissing in dit hoofdstuk zal dus gaan over het selecteren van de juiste organisatievorm 
binnen het IT Risk Management, waarbij input wordt verkregen vanuit de ontwikkelde 
Enterprise Architecturen. De geselecteerde organisatievorm dient de overig gevonden 
problemen gedurende de probleemanalyse op te kunnen lossen, tevens dient de oplossing 
toepasbaar te zijn op de gehele URENCO Group. Met behulp van het gekozen EA 
organisatievorm kunnen er consistente processen, procedures en werkinstructies ontwikkeld 
worden voor het IT Incident Management. 
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6.2. Het beslissingsproces vaststellen 


Binnen dit hoofdstuk zullen diverse criteria opgesteld worden waarop de alternatieven 
beoordeeld worden, dit gebeurt met behulp van een kwantitatieve beslissingstechniek: de 
Simple Multi-Attribute Rating Technique (SMART), zoals omschreven door Goodwin & 
Wright (2010). SMART zal helpen om criteria vast te stellen en deze ook van een weging te 
voorzien, zodat de gegenereerde alternatieven beoordeeld kunnen worden. Aangezien de 
weging van criteria de beslissing sterk kan beinvioeden, zal er tevens een 
gevoeligheidsanalyse worden uitgevoerd, zodat de weging door de beslissers kan worden 
aangepast. 


De uiteindelijke beslissing wordt genomen door de afdeling Finance binnen URENCO 
Nederland B.V., met name de IT specialisten en de Business Relationship Manager zullen 
een belangrijke bijdrage leveren aan het eindoordeel. Tevens kan het Management van 
URENCO Nederland B.V. gevraagd worden voor input bij de beslissing, aangezien deze 
tevens betrokken zijn bij crisissituaties. 


6.3. Criteria opstellen, een schaal en gewichten toekennen 


Om het effect van de verschillende alternatieven meetbaar te maken voor het op te lossen 
probleem, zullen er diverse criteria opgesteld worden. Figuur 6-7. geeft de beslissingsboom 
weer met hierin de relevante criteria inclusief onderlinge samenhang die van toepassing is bij 
de beoordeling van de alternatieve EA organisatievormen. 


NACI 
UU 


Organisatievorm implementeren voor gezamenlijke modellering van het IT Incident Management voor een efficiénte en effectieve afh andeling van IT incidenter 


‘ Wes : Dekkingsgraad 
Implementatie Personeelkosten Aansluiting strategie e ye 
mogelijke IT risico ‘s 
Implementatiekosten Implementatietijd 


a » aa 


Figuur 6-1: De beslissingsboom die van toepassing is bij de beoordeling van de mogelijke Enterprise Architecture 
organisatievormen. De linkerkant van de beslissingsboom (rode variabelen) weergeven de kosten criteria. Het 
midden (groene variabelen) toont de criteria met betrekking tot de opbrengsten. Tot slot weergeeft de rechterkant 
van de beslissingsboom (blauwe variabelen) de risico criteria. 


Om de relatieve belang van de criteria te kunnen uitdrukken, wordt er aan ieder criterium een 
gewicht meegegeven. Dit wordt gedaan met behulp van swing weights (Goodwin & Wright, 
2010). Hierbij worden de verandering (of swing) van de slechtste score naar de beste score 
van een criterium vergeleken met een vergelijkbare verandering in een ander criterium. 
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De alternatieven worden bij ieder criterium met behulp van Direct Rating beoordeeld. Deze 
methode kan worden toegepast voor de moeilijk te kwantificeren variabelen door de 
alternatieven op basis van voorkeur op een intervalschaal van 0 tot 100 te verdelen 
(Goodwin & Wright, 2010). De uiteindelijke beoordeling van alternatieven met behulp van 
Direct Rating en de gewichten die zijn meegegeven aan de criteria zijn in tabe/ 6-7 
weergeven. 


6.4. Alternatieven verzinnen of bestaande mogelijkheden gebruiken 
Voor het opstellen van alternatieven worden twee verschillende technieken toegepast: 


Wetenschappelijke artikelen raadplegen; 
Synectics toepassen (Heerkens & Van Winden, 2012). 


De wetenschappelijke artikelen worden verkregen vanuit het plaatsgevonden 
literatuuronderzoek, zie hoofdstuk 4 “Literatuuronderzoek & Onderzoeksmodel”. Bij synectics 
worden associaties gemaakt met een ander vakgebied. Binnen dit onderzoek wordt een 
uitstap gemaakt naar de wereld van organisatiestructuren, aangezien de algemene theorién 
overeenkomsten vertonen met de geconstateerde problemen binnen het IT Incident 
Management (Boddy, 2011)(Daft, Jonathan & Willmott, 2010). 


In totaal kunnen er vier organisatievormen omschreven worden die van toepassing zijn voor 
dit handelingsprobleem: 


Alternatief 1: Een centraal functionele organisatiestructuur, waarbij een Enterprise 
Architecture afdeling op groepsniveau wordt opgericht. Door middel van een top- 


down benadering wordt in samenwerking met de Business Managers en de IT 
specialisten een Enterprise Architecture opgesteld (Coetsee & Brown, 2010). De EA 
afdeling zorgt tevens voor inrichting van het IT Risk Management en IT Incident 
Management; 

Architecture 2: Decentraal geografische organisatiestructuur, waarbij het opstellen 
van een Enterprise Architecture onder verantwoordelijkheid komt van één van de 
reeds geimplementeerde afdelingen. Deze EA geldt als input voor het opstellen van 
het IT Risk Management door bij ieder gemodelleerde element één of meerdere IT 
risico’s te koppelen (Pauli, Schermann & Krcmar, 2010). De oprichting van het 
Enterprise Architecture Management, IT Incident Management en IT Risk 
Management wordt per productielocatie vorm gegeven door samenwerking van 
verschillende partijen, onder eindverantwoordelijkheid en aansturing van de afdeling 
Compliance; 

Alternatief 3: Horizontale team organisatiestructuur, waarbij ieder kernproces onder 
verantwoordeljikehid komt van een team met alle betrokken stakeholders van 
verschillende afdelingen. De taken, bevoegdheden en verantwoordelijkneden worden 
binnen het team zelf bepaald. Gedurende de ontwerpfase zal allereerst een 
Enterprise Architecture worden opgesteld door middel van samenwerking, waarmee 
vervolgens het IT Risk Management en IT Incident Management vorm gegeven 
kunnen worden. Het is echter wel verstandig om tevens een EA afdeling op 
groepsniveau te plaatsen, zodat er ten minste 6én EA expert in het team aanwezig 
kan zijn; 

Alternatief 4: Matrixstructuur, waarbij bedrijfsactoren verantwoording moeten afleggen 
aan en ondersteund worden vanuit twee managementlagen. Allereerst staan de 
werknemers onder de verantwoordelijkehid van een functionele organisatiestructuur, 
maar worden actoren ingezet op de kernprocessen waarbij tevens een manager 
verantwoordelijk is. Door de dubbele verantwoordelijkneden kunnen Enterprise 
Architecturen opgesteld worden, aangezien de Business Managers en IT specialisten 
samen komen bij de besluitvorming. De implementatie van een EA afdeling is tevens 
nodig. 
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De impact van de verschillende alternatieven op de organisatie kunnen met behulp van de 
EA modelleertaal Archimate 2.0 gevisualiseerd worden. Hierbij wordt slechts de processen 
van het IT Risk Management gemodelleerd inclusief de allocatie van de actoren. De 
modellering is gebaseerd op de essentiéle activiteiten voorgeschreven door Pauli, 
Schermann & Krcmar (2010): (1) risico’s identificatie; (2) Analyse risico’s; (3) Plannen van IT 
Risk Policies; (4) Implementeren van IT Risk Policies; (5) Monitoren van IT risico’s. Deze 
essentiéle maar globale activiteiten worden toegepast omdat de exacte invulling van het IT 
Risk Management pas na de beslissing in dit hoofdstuk vorm gegeven kan worden. De 
essentiéle activiteiten kunnen echter wel aangevuld worden met sub-activiteiten ter 
verduidelijking van het alternatief. 


De volgende figuren geven een visualisatie weer van de vier ontwikkelde alternatieve 
organisatiestructuren: 
e Figuur 6-2 geeft de visualisatie van alternatief 1 weer, de centraal functionele 
organisatistructuur; 
e Figuur 6-3 geeft de visualisatie van alternatief 2 weer, de decentraal geografische 
organisatistructuur; 
e Figuur 6-4 geeft de visualisatie van alternatief 3 weer, de horizontale team 
organisatistructuur; 
e Figuur 6-5 geeft de visualisatie van alternatief 4 weer, de matrix organisatistructuur. 


6.5. Alternatieven beoordelen en gevoeligheidsanalyse 


Nu zowel de criteria, gewichten en alternatieven bekend zijn gemaakt, kunnen de 
verschillende alternatieven beoordeeld worden. Dit wordt gedaan door per criterium te kijken 
hoe elk alternatief scoort met behulp van direct rating, zie tevens Paragraaf W.4. “Criteria 
van een schaal voorzien”. De voor- en nadelen van de ontwikkelde alternatieven (Daft, 
Murphy & Willmott, 2010) worden als input gebruikt voor de score bepalingen. De resultaten 
zijn weergeven in Tabel 6-7, waarbij de alternatieven een totale score krijgen door alle 
scores vermenigvuldigt met de bijoehorende weging op te sommen. Een nadere toelichting 
van de score bepaling is onderaan Tabe/ 6-7 weergeven. 


Alternatief 1 Alternatief 2 Alternatief 3 Alternatief 4 
Criteria i i i i 
Score Weging Score Weging Score Weging Score Weging 
x score x score x score x score 
Consistentie processen & 
procedures 


Kwaliteit communicatie & 
samenwerking 


Effectiviteit besluitsvorming 
Personeelskosten 


Dekkingsgraad mogelijke IT 


risico’s 
Kwaliteit input IT Risk 
Management 
Flexibiliteit wijzigingen 
doorvoeren 
Efficiéntie besluitsvorming 
Aansluiting strategie 
Implementatiekosten 
Implementatietijd 


Tabel 6-1: scores en gewichten van de beslissing omtrent de Enterprise Architecture organisatiestructuur. 
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Bedrijfsprocessen & niterne actoren/rollen 


Identificatie EA © Monitoring IT @® 


risico's 


Periodiek moment 


herziening Analyseren IT => Plannen IT Risk = Implementeren => Monitoren van IT = ; a 
ps Lp risico's —p Policies — van IT Risk — risico's —> Continue monitoring IT 
Policies risico's 
Wijziging in Enterprise ‘a 
Architecture 


Figuur 6-2: Visualisatie van het eerste alternatief met een centraal functionele organisatiestructuur binnen het IT Risk Management. 


Bedrijfsprocessen & interne actoren/rollen | 


Identificatie \dentificatie IT Risico's mbvEA © Analysatie IT © 
EA building risico's 
blocks 


Monitoring IT © 
risico's 


Identificerer IT risico's 


Periodiek moment 


herziening Analyseren|T => Plannen IT Risk => Implementeren => Monitoren van IT = : Si 
Lp Lp risico's Ly Policies Ly van IT Risk Ly risico's > Continue monitoring iT 
Policies risico's 
Wijziging in Enterprise et 
Architecture 


Figuur 6-3: Visualisatie van het tweede alternatief met een decentraal geografische organisatiestructuur binnen het IT Risk Management. 
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Bedrijfsprocessen & interne actoren/rollen 


= oe oS es 


Samenwerking ter opstelling IT Risk Management 


\ se Identificeren IT risico's => 
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Figuur 6-4: Visualisatie van het eerste alternatief met een centraal functionele organisatiestructuur binnen het IT Risk Management. 
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: Figuur 6-5: Visualisatie van het eerste alternatief met een centraal functionele organisatiestructuur binnen het IT Risk Management. 
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De totaalscore kan in de onderste rij van tabe/ 6-7 worden afgelezen, waaruit blijkt dat het 
alternatief van de horizontale teamstructuur veruit het beste scoort. Na uitvoering van een 
gevoeligheidsanalyse is gebleken dat de gekozen oplossing zeer robuust is. Er is namelijk 
geen één criterium dat zodanig veranderd kan worden van waarde, dat de horizontale team 
organisatiestructuur niet meer het optimale alternatief is. Zelfs de matrixorganisatie (de één 
na beste oplossing) komt niet in de buurt van het beste alternatief. Figuur 6-6 geeft een 
voorbeeld weer van de uitgevoerde gevoeligheidsanalyse voor het criterium “Opbrengsten”. 
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Figuur 6-6: de gevoeligheidsanalyse van het criterium “opbrengsten”. 


6.6. Conslusies generatie van alternatieve oplossingen 


Het implementeren van een horizontale teamstructuur blijkt veruit de beste beslissing te zijn, 
zodat er een Enterprise Architecture kan worden ingevoerd ter afhandeling van IT 
Incidenten. Een horizontale teamstructuur scoort uitstekend op de criteria: (1) Consistentie 
processen & procedures; (2) Kwaliteit communicatie & samenwerking; (3) Dekkingsgraad 
mogelijke IT risico’s; (4) flexibiliteit wijzigingen doorvoeren en (5) Efficiéntie besluitsvorming. 


Deze horizontale teamstructuur houdt in dat bij de kKernprocessen alle essentiéle actoren in 
teamverband verantwoordelijk worden gesteld voor de uit te voeren taken. Hierbij zal er 
worden begonnen met het ontwerpen van een Enterprise Architecture, wat als basis dient 
voor het te ontwerpen IT Risk Management en IT Incident Management (Pauli, Schermann & 
Krcmar, 2010). Zie een schematische weergave van de relaties tussen het Enterprise 
Architecture Management en het IT Risk Management in figuur 6-7. 


Search risk 
indicators 


Attach risk indicators © 
to the buildingblocktypes 


Assign values to rr ree | ; 
ha isk MGC ww Export risk indicators > Expertise 
4) EAM IT risk management 
Establish measures: 


Figuur 6-7: Schematische weergave van de integratie tussen IT Risk Management en Enterprise Architecture 
Management (Pauli, Schermann & Kremar, 2010). 


53 


Het implementeren van een team organisatiestructuur heeft volgens Daft, Murphy & Willmott 
(2010) zowel voordelen als nadelen. De voordelen luiden als volgt: 
e Flexibiliteit en snelle reactie op veranderingen in de behoeften van de klant/gebruiker; 
e Aandacht voor diegenen die produceren en waarde toevoegen aan de 
klant/gebruiker; 
e Werknemers hebben een bredere kijk op de organisatorische doelstellingen; 
e Bevorderd teamwerk en samenwerking; 
e Verbeterd de werkomstandigheden door het geven van verantwoordelijkheden aan 
de lagere managementlagen/werknemers. 
Nadelen zijn er echter ook, zoals: 
e Het vaststellen van de kernprocessen is ingewikkeld en kost veel tijd; 
e Veranderingen nodig in ondernemingscultuur, werkomschrijvingen, management 
filosifie, informatiesystemenen en beloningssystemen; 
e Traditionele managers komen in opstand tegen de veranderingen; 
e Significante trainingen nodig voor werknemers om effectief in een team te opereren; 
e Mogelijkheid om de ontwikkeling van in-diepte kennis te belemmeren. 


De voorgestelde samenwerking binnen het IT Risk Management zal dus helpen om de 
gevonden problemen tijdens de probleemanalyse in hoofdstuk 5 te verhelpen. De aandacht 
voor het waarde toevoegen, de bredere kijk van de werknemers op de organisatorische 
doelstellingen en de bevorderde samenwerking zullen helpen om inconsistenties binnen het 
de procedures en werkinsturcties van het IT Incident Management te voorkomen. Dit kan 
worden versterkt door de resulterende documentatie vanuit het IT Risk Management centraal 
op te slaan in het SAP ERP systeem. 


De nadelen van een team organisatiestructuur dienen voor een optimale implementatie 
nader belicht te worden. Het vaststellen van de kernprocessen is ingewikkeld en kost veel 
tijd, echter is hier binnen de URENCO Group al flink wat werk voor verricht, zie bijvoorbeeld 
paragraaf 1.2. “One URENCO strategie”. De beperking van de kennis ontwikkelen zal tevens 
meevallen, omdat de team organisatiestructuur tot op heden slechts worden toegepast bij 
het IT Risk Management en IT Incident Management. De huidige functionele 
organisatiestructuur binnen de primaire productieprocessen blijft onveranderd, wat de 
kennisgeneratie zal waarborgen. De veranderingen in de ondernemingscultuur, de mogelijke 
weerstand van traditionele managers en de benodigde trainingen verdienen echter wel 
aandacht van zorg. Deze zullen nader uitgewerkt worden bij de implementatie van de 
oplossing, zie hoofdstuk 7 “Implementatie”. 
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7. Implementatie 


De oplossing die gedurende hoofdstuk 6 is verkregen, het implementeren van een 
horizontale team organisatiestructuur ter opstelling van het IT Risk Management, zal in dit 
hoofdstuk nader worden uitgewerkt. Tevens zullen de gevolgen voor het IT Incident 
Management besproken worden. Dit wordt gedaan met behulp van een technisch en een 
sociaal implementatieplan: 

e Paragraaf 7.1. omschrijft het technische implementatieplan van het IT Risk 
Management, wat een korte beschrijving omvat van de uit te voeren activiteiten; 

e Paragraaf 7.2. geeft het technische implementatieplan van het IT Incident 
Management weer, resulterend uit het nieuw geimplementeerde IT Risk 
Management. Ook hier wordt een beschrijving van de uit te voeren taken gegeven. 

e = Paragraaf 7.3. omschrijft het sociale implementatieplan, wat inzicht geeft in hoe de 
veranderingen aan de betrokken stakeholders wordt voorgelegd. 


Het technische en sociale implementatieplan van het voorgestelde IT Risk Management zal 
bijdragen om het IT Incident Management effectiever en efficiénter vorm te geven. Dit zal in 
Appendix X “IT Incident Management procedure” nader uitgewerkt worden. 


7.1. Technisch implementatieplan IT Risk Management 


Het technisch implementatieplan zal leiden tot het invoeren van een vernieuwd IT Risk 
Management proces, gebaseerd op de bevindingen van Pauli, Schermann & Krcmar (2010), 
zie hoofdstuk 6 “Generatie van alternatieve oplossingen”. Tevens is het implementatieplan 
gebaseerd op de horizontale team structuur die de gevonden inconsistenties dient op te 
lossen, zie Daft, Murphy & Willmott (2010) en paragraaf 5.6. “Conclusies probleemanalyse’”. 
Tot slot wordt naar eigen inzicht geprobeerd om de verschillende actoren, activiteiten en 
ondersteunende software tot €én geheel te maken. Hieruit resulteert het volgende plan: 


1. Implementeer een centrale Enterprise Architecture afdeling waarin werknemers 
vertegenwoordigd zijn met de benodigde kennis om een Enterprise Architecture op te 
stellen. Dit kan ook als een extra taak aan één van de reeds bestaande afdelingen 
worden toegevoegd, met name de Business Relationship Managemers kunnen deze 
taak uitvoeren (vorm van job enlargment). Zorg tevens voor een geschikte EA 
modelleringstool, ; 


2. Stel voor ieder kernproces van URENCO Nederland B.V. (en de overige 
verrijkingsfacaliteiten) een IT Risk Management team samen, bestaande uit alle 
betrokken stakeholders: 

Business Manager van het desbetreffende proces; 

IT specialisten URENCO Nederland B.V.; 

IT specialisten CSC Limited en overige externe IT leveranciers; 

URENCO Nederland B.V. Plant Maintenance operators; 

Enterprise Architecture Manager of Business Relationship Manager; 

Information Security Manager; 

g. Compliance medewerker. 


“2295p 


3. Verdeel de taken, bevoegdheden en verantwoordelijkheden binnen het team met 
behulp van RASCI matrices, zodat deze taken duidelijk gedocumenteerd kunnen 
worden in de documenten; 


4. Stel een Enterprise Architecture voor het kernproces op met behulp van het 
Enterprise Architecture Framework (Jonkers et al., 2003). Waarborg dat iedere 
stakeholder zijn input kan leveren voor het opstellen van de Enterprise Architecture, 
betrek hierin ook de IT infrastructuur en services van de externe IT leveranciers; 
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9; 


10. 


11. 


12. 


Identificeer de mogelijke IT risico’s die kunnen voorkomen binnen de IT 
infrastructuur van URENCO Nederland B.V. en CSC Limited en koppel deze aan de 
building blocks binnen het gemodelleerde technische domein in de Enterprise 
Architecture met behulp van risico indicatoren. Maak tevens gebruik van de reeds 
plaatsgevonden IT incidenten (IT Incident Log Tickets); 


Bepaal met behulp van de Enterprise Architecture wat de invloed is van een IT 
incident op de applicaties en bedrijfsprocessen. Zorg dat deze duidelijk 
gedocumenteerd worden; 


Stel een Business Impact Analysis op om de kritieke bedrijfsprocessen, applicaties 
en bedrijfsprocessen te bepalen. Weeg de mogelijke risico’s hierbij af tegen de 
verwachte schade (in financiéle criteria of tijd) en sla het document intern op; 


Selecteer de kritieke processen, applicaties en IT componenten vast en ontwikkel 
met alle betrokken stakeholders per kritiek proces: 

a. Een algemeen IT Incident Management activiteitenoverzicht, wat het 
totale IT Incident Management voor alle stakeholders inzichtelijk maakt: 

i. Stel indicatoren op waarmee de operators de reeds bekende IT 
risico’s kunnen identificeren; 
ii. Een duidelijk en consistent proces voor het melden, analyseren, 
repareren en herstellen van mogelijke IT incidenten; 
iii. Criteria en procedures voor het inschakelen van het Crisis 
Management proces. 
b. Een Business Continuity Plan: 
i. Activiteiten voor het melden van het IT incident bij de CSC helpdesk 
of Plant Maintenance operators; 
ii. Een workaround voor het voortzetten van het IT incident; 
iii. Activiteiten voor het herstellen van de productie door de operators. 

c. Een IT Incident Recovery Guide. 

d. Breidt het SAP ERP systeem uit met een link naar het IT Incident Registratie 
Systeem (CSC Unicenter Helpesk System), inclusief een IT incident 
meldingsformulier en een dashboard waar de voortgang van IT incidenten 
voor alle stakeholder inzichtelijk wordt gemaakt. 


Implementeer de opgestelde IT Risk Management documenten nadat alle betrokken 
stakeholders de voorgestelde procedures hebben goedgekeurd. Zorg voor een 
centrale digitale opslag van alle documenten binnen het SAP ERP systeem, zodat de 
stakeholders ieder moment de procedures kunnen raadplegen. De afdeling 
Compliance dient toe te zien dat er maximaal één versie van elk benodigd document 
op het systeem worden geuploaded; 


Licht de betrokken operators in over de ingevoerde procedures en licht toe hoe de 
operators een IT risico kunnen identificeren en melden; 


Zorg voor constante monitoring van de mogelijke IT risico’s door de kritieke 
onderdelen in de Enterprise Architecture te monitoren. Dit kan zowel via Remote 
Monitoring als door de controle door gebruikers; 


Houdt ieder teamlid verantwoordelijk voor het doorvoeren van wijzigingen in de 
Enterprise Architecture, zodat de procedures aangepast kunnen worden. Regel ten 
minste 6én maal in de maand een vergadering om veranderingen in de 
bedrijfsprocessen, applicaties en technologische infrastructuur te bespreken. 
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Het belangrijkste is dat de combinatie van een Enterprise Architecture met het IT Risk 
Management helpt om de belangen en activiteiten van alle stakeholders op elkaar af te 
stemmen, zodat IT incidenten zo effectief en efficiént mogelijk opgelost kunnen worden. 
Figuur 7-1 geeft een globale visualisatie weer van het voorgestelde technische 
implementatieplan betreffende het IT Risk Management. Voor het gemak is de technische 
modellering buiten beschouwing gelaten, aangezien deze onveranderd is. 


7.2. Technisch implementatieplan IT Incident Management 


Tijdens het IT Risk Management zullen de procedures ontwikkeld worden die als input 
gelden bij het IT Incident Management, zoals een algemeen IT Incident Management 
activiteitenoverzicht, Business Continuity Plans en IT incident revcovery guides. Het is de 
taak van het IT Risk Management team om deze documenten op maat te maken voor het 
desbetreffende proces wat onderhanden wordt genomen. Echter kunnen er wel procedures 
Op groupsniveau opgesteld worden die als input gebruikt kunnen worden door het IT Risk 
Management team. 


Appendix X “IT Incident Management procedure” weergeeft een voorbeeld van het algemene 
IT Incident Management activiteitenoverzicht, dit document geldt als template voor alle 
kernactiviteiten binnen de URENCO Group. Figuur 7-2 geeft een globale visualisatie van de 
voorgestelde procedure. De procedure is gebaseerd op het gewenste IT Incident 
Management in figuur 5-9. Vanuit de voorgestelde IT Incident Management procedure kan 
het volgende implementatieplan opgesteld worden: 


1. Modelleer zowel het URENCO als CSC IT Incident Management in dezelfde 
documentatie, zodat misverstanden omtrent de meldingen worden voorkomen; 


2. Breidt het SAP ERP systeem uit met een functie om alle IT incidenten centraal te 
kunnen registreren, zowel voor IT incidenten in beheer van URENCO als van CSC. 
De process operators kunnen handmatig het defecte IT systeem/component 
selecteren, zodat de IT incident log ticket automatisch aan de juiste actor ter wordt 
verstuurd; 


3. Breidt het SAP ERP systeem uit met een functie om na registratie van het IT 
incident (zowel handmatig als via monitoring) het desbetreffende Business 
Continuity Plan beschikbaar te stellen aan de process operators en Process 
Owner. Zo kunnen de process operators de workaround opstarten ter continuiteit van 
de productie; 


4. Breidt het SAP ERP systeem uit met een dashboard waar de Process Owner en 
process operators de voortgang van het IT Incident Management proces kunnen 
volgen. Dit helpt bij het plannen van de verstoorde productie; 


5. Wijzig de criteria ter classificatie van het IT Incident binnen URENCO Nederland 
B.V., hanteer de severity levels zoals is afgesproken met de externe IT leverancier 
CSC zodat misverstanden worden voorkomen; 


6. Stel een actor verantwoordelijk voor het analyseren en classificeren van IT 
incidenten binnen de IT van URENCO Nederland B.V. zelf. De grootste kanshebber 
hiervoor is de Plant Maintenance Manager en/of de Plant Maintenance operators; 


7. Vereenvoudig de herstelling van de IT services door de Process Operator 


eindverantwoordelijk te maken, met ondersteuning van de IT resolver groups en 
process operators. 
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Figuur 7-1: Visualisatie van het voorgestelde IT Risk Management, waarbij gebruik wordt gemaakt van 


een horizontale team organisatiestructuur. 
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Bedrijfsprocessen & niterne actoren/rollen 
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Figuur 7-2: Modellering van de IT Incident Management procesomschrijving, inclusief de betrokken applicaties en applicatie services. 
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Vanuit het IT Incident Management implementatieplan kan geconcludeerd worden dat de 
meeste aanpassingen te maken hebben met invoeren van nieuwe functionaliteiten binnen 
het SAP ERP systeem. De IT incident registratie dient namelijk centraal te verlopen, zodat 
informatie gemakkelijk bij de juiste actoren terecht kan komen. Figuur 7-3 weergeeft het 
voorgestelde Class Diagram van de nieuwe informatie die in het SAP ERP systeem 
opgeslagen dient te worden. 


In relatie met 


> informeert 


<voertin 1..* 


a __UNL Process Ope =] 
SSS 


ant Maintenance Manager_ 


> In behandeling genomen door 


Figuur 7-3: Class Diagram voor het SAP ERP systeem binnen het alternatieve IT Incident Management. 


7.3. Sociaal implementatieplan 


Binnen URENCO Nederland B.V. is de afgelopen jaren geprobeerd om de ONE URENCO 
strategie toe te passen door middel van een top-down implementatie vanuit het 
hoofdkantoor. Dit heeft echter niet de inconsistenties binnen het IT Risk Management en het 
IT Incident Management kunnen verhelpen. Vandaar dat het bij de implementatie van het 
technisch plan ten zeerste wordt aangeraden om eerst input te verzamelen van alle 
betrokken stakeholders. De volgende aspecten dienen duidelijk gemaakt te worden voordat 
het technisch implementatieplan daadwerkelijk wordt uitgevoerd: 


1. Breng ik kaart welke problemen de stakeholders ervaren met het huidige IT Risk 
Management en IT Incident Management; 

2. Laat zien dat de horizontale team structuur puur wordt geimplementeerd om voor alle 
stakeholders een efficiénte en effectieve afhandeling van IT incidenten mogelijk te 
maken, zodat frustraties weggenomen kunnen worden; 

3. Zorg dat de stakeholders achter het besluit staan om zelf de verantwoordelijkheid in 
handen te nemen en een bijdrage leveren aan de Enterprise Architecture; 

4. Waarborg dat iedere afdeling een gelijke stem heeft bij het opstellen van de 
procedures, zodat alle problemen daadwerkelijk worden verholpen; 

5. Vervul trainingen voor alle stakeholders zodat het werken met een Enterprise 
Architecture en het werken in teamverband tot kwalitatieve procedures leidt. 

6. Vervul trainingen voor de process operators, Process Owners, Plant Maintenance 
Manager en UNL IT resolver groups om alle IT incidenten via het SAP ERP systeem 
te registreren. 

7. Overleg de noodzaak van centrale registratie met de Plant Maintenance Manager. 
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8. Conclusies en aanbevelingen 


8.1. Het centrale handelingsprobleem 


Het afgelopen decenium is er binnen de URENCO Group getracht om een strategie te 
implementeren waarbij alle verrijkingslocaties dezelfde processen hanteren voor het licht 
verrijken van uranium. Een belangrijk element hierbij was het extern uitbesteden van het 
implementeren en beheren van de informatietechnologie, zodat kosten bespaard konden 
worden en de focus bij de kernprocessen kon worden gelegd. Deze strategie heeft echter tot 
inconsistenties binnen het IT Incident Management van URENCO Nederland B.V. geleid. 
Alhoewel de essentiéle procedures en instructies aanwezig zijn en voldoen aan de wettelijke 
eisen, blijkt uit dit onderzoek dat de integratie van de verschillende documenten en de 
samenwerking tussen actoren geoptimaliseerd kan worden. Deze optimalisatie is gericht op 
het efficiénter en effectiever afhandelen van de mogelijke IT incidenten binnen de logistieke 
activiteiten van URENCO Nederland B.V.. Het volgende handelingsprobleem centraal: 
Handelingsprobleem Urenco Nederland B.V.: De efficiénte en effectieve afhandeling van 
IT incidenten binnen de primaire logistieke processen van URENCO’s Nederlandse afdeling 
“Materials Handling” raakt in het geding door het gebrek aan een gezamenlijke modellering 
van de informatietechnologieén, applicaties en bedrijfsprocessen. 

Om de gebreken in kaart te brengen, is er een onderzoeksmodel opgesteld die is gebaseerd 
op het Architecture Framework van Jonkers et al. (2003), zie tevens figuur 4-4. Met dit model 
zijn er Enterprise Architecturen opgesteld voor de informatievoorziening binnen de primaire 
logistieke activiteiten, het IT Risk Management en het IT Incident Management. 
Inconsistenties zijn opgespoord met behup van een Gap Analysis (The Open Group, 2011). 


Om het onderzoek te structureren zijn de volgende deelvragen opgesteld en tevens 
beantwoord: 


1. Wat zijn de voordelen voor het IT Incident Management, zodra de 
informatietechnologie, applicaties & bedrijfsprocessen gezamenlijk worden 
gemodelleerd?; 


2. Hoe is de informatievoorziening binnen de logistieke processen van URENCO’s 
Nederlandse afdeling “Materials Handling” momenteel ingericht, gezien vanuit een 
gezamenlijke modellering van de informatietechnologie, applicaties & 
bedrijfsprocessen?; 


3. Hoe is momenteel het IT Incident Management ingericht binnen de logistieke 
processen van URENCO’s Nederlandse afdeling “Materials Handling”, gezien vanuit 
een gezamenlijke modellering van de informatietechnologie, applicaties & 
bedrijfsprocessen?; 


4. Welke beperkingen zijn er binnen het IT Incident Management met betrekking tot de 
informatietechnologie, applicaties & bedrijfsprocessen die worden gebruikt door 
URENCO’s Nederlandse afdeling “Materials Handling”? 


5. Hoe kan de aansluiting van het IT Incident Management op de informatievoorziening 
geoptimaliseerd worden binnen de logistieke processen van URENCO’s Nederlandse 
afdeling “Materials Handling”?; 


6. Hoe kan een raamwerk worden opgesteld ter ontwikkeling van een consistent IT 
Incident Management beleid binnen de gehele URENCO Group? 
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8.2. Beantwoording onderzoeksvragen 


8.2.1. Beantwoording onderzoeksvraag 1 — EA voordelen 
Vanuit de doorzochte wetenschappelijke literatuur zijn er meerdere voordelen van een 


Enterprise Architecture benoemd die specifiek het IT Incident Management van URENCO 
Nederland B.V. kunnen verbeteren, zie tevens paragraaf 5.2. “Probleemanalyse 
onderzoeksvraag 1”. De eigenschappen van een Enterprise Architecture (benefit enablers) 
resulteren namelijk in de volgende organisatorische voordelen: (1) verbeterde input IT Risk 
Management; (2) verbeterde communicatie en samenwerking; (3) effectiever en versnelde 
besluitsvorming, (4) effectiever en efficiénter Change Management en (5) afstemming 
bedrijfsprocessen en procedures. Deze voordelen bieden hulp om de geconstateerde 
beperkingen binnen het IT Incident Management (en IT Risk Management) m.b.v. een 
Enterprise Architecture op te lossen. Ook kunnen deze verwachte voordelen als criteria 
worden toegepast bij het kiezen van de uiteindelijke oplossing. 


8.2.2. Beantwoording onderzoeksvraag 2 — EA modellering primaire logistieke processen 

In paragraaf 5.3. “Probleemanalyse onderzoeksvraag 2” zijn de resulterende Enterprise 
Architectures van de primaire logistieke activiteiten gemodelleerd. Deze modellen laten zien 
op welke processen en systemen het IT Risk Management en IT Incident Management van 
toepassing zijn. Tevens bieden deze Enterprise Architectures de kans om de inconsistenties 
binnen het IT Risk Management en IT Incident Management te elimineren. 


8.2.3. Beantwoording onderzoeksvraag 3 — EA modellering IT Incident Management 

In paragraaf 5.4. “Probleemanalyse onderzoeksvraag 3” zijn de resulterende Enterprise 
Architectures van het IT Incident Management weergeven. Belangrijk om te melden is dat er 
twee belangrijke partijen zijn binnen het IT Incident Management.De technische staf binnen 
URENCO Nederland B.V. verhelpt met name de IT Incidenten binnen het classified netwerk. 
De externe IT leverancier CSC verwerkt de IT incidenten binnen het in-confidence netwerk 
met behulp van een helpdeks en diverse resolver groups. De toegepaste procedures en 
werkinstructies worden aangemaakt met behulp van het IT Risk Management, zowel 
URENCO Nederland B.V. als CSC Limited hanteren hun eigen processen hiervoor. 


8.2.4. Beantwoording onderzoeksvraag 4 — Gap Analyse 

De huidige modelleringen en gewenste EA modelleringen worden in paragraaf 5.5. 
“Probleemanalyse onderzoeksvraag 4” met behulp van Gap Analyses met elkaar vergeleken, 
zodat inconsistenties opgezocht kunnen worden. De problemen binnen het IT Risk 
Management en IT Incident Management blijken voornamelijk van organisatorische aard te 
zijn, de meeste problemen resulteren namelijk vanuit de Business Layer Gap Analyses. De 
actoren binnen URENCO Nederland B.V. en CSC Limited hanteren elk hun eigen 
systeemomschrijvingen, procedures en definities.Ook is de voortgang van IT Incident 
Management niet transparant voor alle actoren. Binnen het IT Risk Management onbreekt 
een gezamenlijke codrdinatie en een centrale opslag van de opgestelde documentatie. 


De problemen binnen het IT Incident Management kunnen grotendeels verklaard worden 
door de inconsistenties die bestaan binnen het IT Risk Management, hier worden de 
procedures en werkinstructies namelijk vorm gegeven. Het hervormen van het IT Risk 
Management zal dus leiden tot een consistent IT Incident Management, zodat IT incidenten 
effectief en efficiént afgehandeld kunnen worden. Met name de organisatievorm vormt hierbij 
een punt van aandacht. 


8.2.5. Beantwoording onderzoeksvraag 5 — alternatief IT Incident Management 

Om het IT Incident Management te optimaliseren, zijn er in hoofdstuk 6 vier alternatieve 
organisatievormen gegenereerd ter ondersteuning van het IT Risk Management: (1) Centraal 
functionele organisatiestructuur; (2) Decentraal geografische organisatiestructuur; (3) 
Horizontale team organisatiestructuur; (4) Team structuur. 
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Het implementeren van een horizontale teamstructuur binnen het IT Risk Management blijkt 
veruit de beste oplossing te zijn, zodat er een Enterprise Architecture kan worden ingevoerd 
ter afhandeling van IT Incidenten. Een horizontale teamstructuur scoort uitstekend op de 
criteria: (1) Consistentie processen & procedures; (2) Kwaliteit communicatie & 
samenwerking; (3) Dekkingsgraad mogelijke IT risico’s; (4) flexibiliteit wijzigingen doorvoeren 
en (5) Efficiéntie besluitsvorming. 


Deze horizontale teamstructuur houdt in dat bij de kKernprocessen alle essentiéle actoren in 
teamverband verantwoordelijk worden gesteld voor de uit te voeren taken. Hierbij zal er 
worden begonnen met het ontwerpen van een Enterprise Architecture, wat als basis dient 
voor het te ontwerpen IT Risk Management en IT Incident Management (Pauli, Schermann & 
Krcmar, 2010). De procedures en werkinstructies die ontwikkeld worden dienen centraal te 
worden opgeslagen in het SAP ERP systeem. 


8.2.6. Beantwoording onderzoeksvraag 6 - raamwerk URENCO Group 
Het implementatieplan in hoofdstuk 7 geeft weer hoe het vernieuwde IT Risk Management in 


de gehele organisatie verwerkt kan worden, figuur 7-7 toont een visualisatie hiervan. 
Belangrijk is het dat per verrijkingslocatie wordt gekeken welke primaire processen er zijn, 
voor ieder proces dient een IT Risk Management team samengesteld te worden. Tevens 
dient er een aparte Enterprise Architecture afdeling te worden geimplementeerd op 
groepsniveau, zodat elk team kan worden aangevuld met de juiste kennis voor het in kaart 
brengen van de informatievoorziening. Nadat alle teamleden goedkeuring hebben gegeven 
voor de implementatie van de procedures en werkinstructies resulterend uit het IT Risk 
Management, dienen de documenten centraal opgeslagen te worden in het SAP ERP 
systeem. Zo zijn de procedures en werkinstructies consistent, gemakkelijk te vinden en voor 
iedereen transparant. 


Alhoewel de IT Risk Management teams verantwoordelijk zijn voor de opstelling van IT 
Incident Management procedures, kan er een algemene template worden ontwikkeld met de 
essentiéle kernactiviteiten: (1) Rapporteren IT incident; (2) Analyseren en classificeren IT 
incident; (3) Toewijzen IT resolver group; (4) Oplossen IT incident en (5) Herstellen IT 
services. Figuur 7-2 geeft de template weer voor het alternatieve IT Incident Management 
proces. Het proces dient met name vereenvoudigd te worden tot de kerntaken, terwijl het IT 
Incident Management proces van zowel URENCO als CSC tegelijkertijd gemodelleerd 
worden. Daarnaast dient het SAP ERP systeem als centrale registratie en 
communicatiemiddel toegepast te worden. 


8.3. Aanbevelingen 


Om de afhandeling van IT incidenten effectief en efficiént te doen verlopen, wordt er 
aangeraden om de organisatievorm van het IT Risk Management te herzien. Hierdoor zullen 
de procedures en werkinstructies consistent vorm gegeven worden, zodat de samenwerking 
en besluitvorming verbeterd kan worden. Het wordt URENCO Nederland B.V. aanbevolen 
om het IT Risk Management door middel van een team vorm te laten geven, in dit team 
dienen alle betrokken actoren bij het afhandelen van IT incidente een gelijke stem te hebben. 
Tevens wordt aanbevolen om het opstellen van een Enterprise Architecture centraal te 
stellen bij het vinden van de mogelijke IT risico’s, in combinatie met het analyseren van de 
reeds plaatsgevonden IT incidenten. Op deze manier wordt ook duidelijk hoe de 
informatievoorziening er precies uit ziet. Hiervoor dient dus een nieuwe Enterprise 
Architecture afdeling op groepsniveau te worden geimplementeerd. Tot slot zal het opstellen 
van een IT Incident Management procedure als template gebruikt kunnen worden door het IT 
Risk Management Team, waarbij IT incidenten voor zowel CSC als URENCO centraal 
geregistreerd worden in het SAP ERP Systeem. 


63 


Deze aanbeveling zal aan het management van URENCO Nederland B.V. voorgelegd 
worden ter evaluatie, met name de inzichten van de Business Relationship Manager worden 
hierbij gevraagd. Bij mogelijke implementatie van de uiteindelijke oplossing wordt er 
aangeraden om bij één proces te beginnen, bij voorkeur de primaire logistieke activiteiten 
binnen de afdeling “Materials Handling”. Hier is namelijk al het meeste modelleerwerk voor 
verricht. Met behulp van de rapporten die CSC maandelijks opleverd betreffende het IT 
Incident Management, kan er worden gekeken of de effectiviteit en efficiéntie daadwerkelijk 
bevorderd is. Bij positief resultaat kan het concept eenvoudig worden uitgebreid naar overige 
processen, aangezien de daadwerkelijke productie niet door de aangedragen oplossing 
wordt beinvioed. 


8.4. Beperkingen & toekomstig werk 


Binnen het plaatsgevonden onderzoek en de aangedragen oplossing zijn er echter wel nog 
enige beperkingen: 

e Het onderzoek heeft zich met name gericht op de documentatie die binnen URENCO 
Nederland B.V. beschikbaar was omtrent het IT Incident Management. Enige 
interviews zijn er wel uitgevoerd ter verduidelijking, maar de essentie van het 
onderzoek lag bij het doorzoeken van de reeds geimplementeerde procedures en 
werkinstructies. De gevonden problemen dienen nog voorgelegd te worden aan de 
medewerkers binnen het IT Incident Management van de primaire logistieke 
processen ter validatie; 

e Het EA Benefits model van Tamm et al. (2011) is toegepast om de organisatorische 
voordelen van een Enterprise Architecture in kaart te brengen. Echter is er niet 
gekeken naar de invloed die de kwaliteit van een Enterprise Architecture heeft. 
Aangezien dit van invloed kan zijn op de prestaties van de uiteindelijke procedures en 
werkinstructies, wordt het ten zeerste aangeraden om te onderzoeken hoe een EA 
kwalitatief van hoge kwaliteit kan worden gemaakt; 

e De gewenste Enterprise Architecturen zijn gebaseerd op de gevonden 
wetenschappelijke literatuur en de doelstellingen die URENCO en CSC zich zelf 
hebben opgelegd, de exacte invulling is gemaakt naar inzien van de auteur (Martijn 
Koot). Ter validatie kan er worden gekeken naar mogelijke oplossingen die al 
bestaan binnen het bedrijfsleven, hier heeft dit onderzoek geen aandacht aan 
besteed; 

e Dewegingen en scores die zijn toegepast bij het kiezen van een alternatieve 
organisatievorm zijn gebaseerd op de auteur van dit onderzoek (Martijn Koot). Deze 
wegingen en scores dienen gecontroleerd te worden door de Business Relationship 
Manager. Aanpassing van de criteria, scores en gewichten is altijd nog mogelijk, 
echter wordt er na uitvoering van de gevoeligheidsanalyse niet veel verandering in de 
uiteindelijk voorgestelde keuze verwacht; 

e De aangedragen oplossing is momenteel nog niet getest op zijn prestaties. Dit kan 
worden uitgevoerd met behulp van de rapporten die CSC opleverd met betrekking tot 
het IT Incident Management. Het dient dus onderzocht te worden of de oplossing 
daadwerkelijk de efficiéntie en effectiviteit van de IT incidenten afhandeling 
bevorderd; 

e De aangedragen oplossing is toepasbaar op alle primaire processen binnen de 
URENCO Group, ook de processen en systemen die vallen onder het classified 
netwerk. Echter is er bij de oplossing uitgegaan van het feit dat IT Incidenten 
Registratiesysteem van CSC voor alle IT incidenten toegankelijk was. CSC richt zich 
echter op het in-confidence netwerk, niet het classified netwerk. Er moet nog nader 
onderzocht worden of deze link mogelijk is. 
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